Hi Tobias,
On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape Das.Linux@gmx.de wrote:
Dear Eliot, all
Am 24.09.2013 um 20:16 schrieb Eliot Miranda eliot.miranda@gmail.com:
Thanks Marcel!! Can I fold this into my makefiles?
Is gcc 3 really necessary for Cog? “yes” clearly is a proper answer, but last year, as I had to fiddle with the Self VM and make it compile, even Old gcc4 were a pain.
All I wanted to do was to thank Marcel for his advice on setting up a functional build environment, and include whatever parts of that were relevant. I am actually trying to use gcc 4 for cygwin but this is on the back burner because the win32api headers in latest cygwin releases were damaged when last I tried to build (it appears someone has supplied the 64-bit version in the 32-bit context, grr...). I tried to set up the Makefile to select either gcc3 or gcc4 depending on cygwin version. I was doing this primarily to build a correct SqueakSSL plugin, which would not build with the older win32 api in the older gcc3-based cygwin I've been using since 2009. Alas I failed to build using a more up-to-date cygwin. So you can imagine I was very pleased to see that Marcel had made progress.
So IMO, no gcc 3 should *not* be necessary to build Cog. But a functional build environment is needed, and right now I don't have a funcitonal gcc4-based build environment :-(
Anyone who wants to try and fix this is very welcome. I can supply them with the Makefile that selects the appropriate gcc version. So far I have this in my not-yet-checked-in experimental Makefile:
# C compiler settings (gcc-3.4.4 cygwin 1.5.25(0.156/4/2) vs gcc-4.5.2 1.7.17(0.262/5/3)) # determine cygwin version using uname -r # # determine "old" (eg 1.5.25(0.156/4/2)) or "new" cygwin (eg 1.7.17(0.262/5/3)) ifeq ($(shell ls /usr/bin/i686-pc-mingw32-gcc.exe),/usr/bin/i686-pc-mingw32-gcc.exe) NEWMGW=true endif
ifdef NEWMGW CC:=i686-pc-mingw32-gcc else CC:=gcc endif
Ian apparently has done some tweaks to the build system
for the win32 branch[1]. It also uses MSYS and MinGW but probably more recent gcc'en (but I'm not sure)[2]. Just out of curiosity, have you sync'ed the cog-branch platform dir after the initial branching?
Not carefully. I try to merge when I see relevant changes going into trunk, but I've probably missed a few.
Please do not regard me as a show stopper or „Spaßbremse“, but I figure, that the entry barrier to work with the Squeak VM or Cog is quite high, even if you don't want touch the interpreter/jit at all. We should make it more approachable.
+1000. But I need help. I don't have time to attend to this now :-(
I think Mariano did a good job for an introduction to building a Squeak/Cog VM[3], But his 2nd-level tool-chain (sources from gitorious+CMake via CMakeVMMaker)[4] seems vastly different from the current Makefile-based approach, but apparently, the CMake toolchain can make use of more recent compilers.
Where are we headed?
Onwards and upwards ;-) Personally I hate both autoconf and CMake, but better the devil you know, and have hence stuck with autoconf on unix. On Mac & cygwin I use ungenerated makefiles. I'm open to change but I don't want to do the work. If someone can help produce functional build environments I'll gladly try them out and fold them back in if they work. But they must work for the Squeak VM, the Squeak MT VM and the Newspeak VM. That's what I build across three platforms right now and I don't want to waste the cycles trying to get new stuff to work with no guarantee of success... Call me a cynic ;-)
Best -Tobias
[1] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/ [2] http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/HowToBui... [3] https://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us... [4] I would call the MSYS+MinGW tool-chain 1st level in this case