Two commits part 1 - copied build.win64x64/pharo.cog.spur to build.win32x86/pharo.cog.spur part 2 - tuned latter to build a stack vm You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/317
-- Commit Summary --
* Add pharo.stack.sput, part 1 - direct copy of pharo.cog.spur * Add pharo.stack.spur, part 2 - modify cog build into stack uild
-- File Changes --
A build.win32x86/pharo.stack.spur/Makefile (38) A build.win32x86/pharo.stack.spur/Pharo.def.in (3) A build.win32x86/pharo.stack.spur/Pharo.exe.manifest (30) A build.win32x86/pharo.stack.spur/Pharo.ico (0) A build.win32x86/pharo.stack.spur/Pharo.rc (32) A build.win32x86/pharo.stack.spur/mvm (34) A build.win32x86/pharo.stack.spur/plugins.ext (9) A build.win32x86/pharo.stack.spur/plugins.int (40)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/317.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/317.diff
I've rebased this away from my serial-fix-attempt onto the latest HEAD with Eliot's fix. ```build.win32x86/pharo.stack.spur/mvm -d``` succeeded on my machine.
This is the same error I initially got on my local machine with last week's HEAD. Then I went back a few dozen commits and that Freetype build worked okay, then when I returned to the HEAD commit, it now worked. Huh!? No clue here. see... http://forum.world.st/Freetype-ftconfig-h-missing-td5089946.html ``` -- Build files have been written to: /cygdrive/c/projects/vm/build.win32x86/pharo.cog.spur/build/third-party/freetype-2.9.1/build make[3]: Entering directory '/cygdrive/c/projects/vm/build.win32x86/pharo.cog.spur/build/third-party/freetype-2.9.1/build' [100%] Linking C shared library libfreetype.dll [100%] Built target freetype [100%] Built target freetype Install the project... -- Installing: /cygdrive/c/projects/vm/.thirdparty-cache/windows/i386/include/freetype2/freetype/config/ftheader.h ...etc... -- Installing: /cygdrive/c/projects/vm/.thirdparty-cache/windows/i386/include/freetype2/ft2build.h CMake Error at cmake_install.cmake:35 (file): file INSTALL cannot find "/cygdrive/c/projects/vm/build.win32x86/pharo.cog.spur/build/third-party/freetype-2.9.1/build/include/freetype/config/ftconfig.h". make[1]: *** [Makefile:62: install] Error 1 make[1]: Leaving directory '/cygdrive/c/projects/vm/build.win32x86/pharo.cog.spur/build/third-party/freetype-2.9.1/build' make: *** [../third-party/Makefile.freetype2:25: /cygdrive/c/projects/vm/.thirdparty-cache/windows/i386/bin/libfreetype.dll] Error 2 Command exited with code 1 ```
Hi Ben,
Are you sure you didn't just go back to using the previous version of freetype (pre 2.9.1)?
If you do have 2.9.1, do you know which commit you went back to?
I'm still not able to build on windows :-(
Thanks, Alistair
nope. freetype-2.9.1 also fails... $ git clone --depth 10 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git checkout HEAD~9 $ cd build.win32x86/pharo.cog.spur To fail faster... $ vi Makefile # to ignore the other libraries... ``` THIRDPARTYLIBS:=freetype2 ``` $ ./mvm -d
``` file INSTALL cannot find "/home/Ben/Repos/depth10/opensmalltalk-vm/build.win32x86/pharo.cog.spur/builddbg/third-party/freetype-2.9.1/build/include/freetype/config/ftconfig.h". make[2]: *** [Makefile:62: install] Error 1 make[2]: Leaving directory '/home/Ben/Repos/depth10/opensmalltalk-vm/build.win32x86/pharo.cog.spur/builddbg/third-party/freetype-2.9.1/build' make[1]: *** [../third-party/Makefile.freetype2:25: /home/Ben/Repos/depth10/opensmalltalk-vm/.thirdparty-cache/windows/i386/bin/libfreetype.dll] Error 2 ```
I opened a new issue #319 for the freetype error introduced two weeks ago.
nicolas-cellier-aka-nice commented on this pull request.
@@ -0,0 +1,38 @@
+############################################################################# +# Makefile for Win32 Stack Spur PharoVM using gcc and cygwin +# Do make init to allow make -n to function. +############################################################################# + +VM:=Pharo +VM_NAME:=Pharo Virtual Machine + +VMSRCDIR:=../../spurstacksrc/vm +# NOTES: +# STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). +# ALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, +# then FFI module needs to adjust that. It is NOT the case of mingw. +# For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.ht... +#COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
These comments are troubling... Either these flags are necessary as the comment tells... but then why don't we find them in code? ... or they are not anymore to date and should be removed. I know you did not add these lines by yourself, only copied them, but someone forgot to clean up, so while at it... (All these changes are marked as authored by Esteban, but I'm pretty sure that it was me who did perform the cleanup; at the time when wanting to work in a parallel pharo repository, git was somehow missused!)
nicolas-cellier-aka-nice commented on this pull request.
@@ -0,0 +1,38 @@
+############################################################################# +# Makefile for Win32 Stack Spur PharoVM using gcc and cygwin +# Do make init to allow make -n to function. +############################################################################# + +VM:=Pharo +VM_NAME:=Pharo Virtual Machine + +VMSRCDIR:=../../spurstacksrc/vm +# NOTES: +# STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). +# ALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, +# then FFI module needs to adjust that. It is NOT the case of mingw. +# For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.ht... +#COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
Or maybe I just gave instructions in commit message e9ff2f20501ee86801747f06f653fd669e138de9 ? Failure to cleanup is not only mine, it's collective then ;)
Hi Nicolas, the flags are necessary (but one is misnamed). See platforms/Cross/vm/sqCogStackAlignment.h for use and default definition of STACK_ALIGN_BYTES. See src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c for use of ALLOCA_LIES_SO_SETSP_BEFORE_CALL. But ALLOCA_LIES_SO_SETSP_BEFORE_CALL is set up by X64Win64FFIPlugin.c so we don't need it on the command line.
bencoman commented on this pull request.
@@ -0,0 +1,38 @@
+############################################################################# +# Makefile for Win32 Stack Spur PharoVM using gcc and cygwin +# Do make init to allow make -n to function. +############################################################################# + +VM:=Pharo +VM_NAME:=Pharo Virtual Machine + +VMSRCDIR:=../../spurstacksrc/vm +# NOTES: +# STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). +# ALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, +# then FFI module needs to adjust that. It is NOT the case of mingw. +# For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.ht... +#COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
you are right, I just copied those lines from pharo.cog.spur. But is this PR the place to fix these? This PR is focused on build.win64x64/pharo.cog.spur and your concern seems a broader issue...
``` $ find opensmaltalk-vm -name Makefile -print -exec grep STACK_ALIGN_BYTES {} ;
./build.win32x86/pharo.cog.spur/Makefile # STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). #COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
./build.win32x86/pharo.cog.spur.lowcode/Makefile # STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). #COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
./build.win32x86/pharo.sista.spur/Makefile # STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). #COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
./build.win32x86/squeak.cog.spur.lowcode/Makefile COGDEFS:= -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0 ```
nicolas-cellier-aka-nice commented on this pull request.
@@ -0,0 +1,38 @@
+############################################################################# +# Makefile for Win32 Stack Spur PharoVM using gcc and cygwin +# Do make init to allow make -n to function. +############################################################################# + +VM:=Pharo +VM_NAME:=Pharo Virtual Machine + +VMSRCDIR:=../../spurstacksrc/vm +# NOTES: +# STACK_ALIGN_BYTES=16 is needed in mingw and FFI (and I suppose on other modules too). +# ALLOCA_LIES_SO_USE_GETSP=0 Some compilers return the stack address+4 on alloca function, +# then FFI module needs to adjust that. It is NOT the case of mingw. +# For more information see this thread: http://forum.world.st/There-are-something-fishy-with-FFI-plugin-td4584226.ht... +#COGDEFS:= -DPharoVM=1 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0
Of course, changes can be post-poned after this PR. i just said "_while at _it__"
I solved the freetype-2.9.1 build error in issue #319. It was an upstream problem unrelated to this PR. Is there anything remaining to prevent this PR being merged?
Merged #317 into Cog.
vm-dev@lists.squeakfoundation.org
-
akgrant43 -
Ben Coman
-
Eliot Miranda
-
Nicolas Cellier