Hi all --
All 32-bit builds are fine by now. https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
To my knowledge, there are two remaining issues with the ARM64 builds:
- Pushing struct args that are larger than 16 bytes - FFICallbacks (not Alien)
The issue with the struct args I did flag in the FFI tests.
However, I will take another look at FFI callbacks crashing the VM on Tuesday. Yet, projects out there are more likely to use Alien callbacks than SqueakFFI callbacks. So this is not a big issue. I just want to be sure that it is basically unrelated to the IA32ABI plugin.
Sorry for the delay. Feel free to start testing this commit right now: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
Happy Easter!
Best, Marcel Am 08.04.2022 17:12:34 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
It looks like all urgent fixes have made it into the Cog branch by now. I think we can make a new release candidate at the beginning of next week. :-)
We just have to: - Re-generate the sources for VMMaker.oscog-mt.3178 to include #primitiveMultipleBytecodeSetsActive and #primitiveBytecodeSetsAvailable (thanks Dave!) - Figure out two minor issues in the 32-bit build concerning callbacks and (longlong) type coercion in the SqueakFFIPrims plugin; if not, should not be a show stopper :-)
Best, Marcel Am 06.01.2022 16:05:14 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.... Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel