[Vm-dev] [HowTo] Compile CogVM for Windows 7 using MinGW/MSYS
Das.Linux at gmx.de
Tue Sep 24 22:34:11 UTC 2013
Am 24.09.2013 um 23:28 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Tobias,
> On Tue, Sep 24, 2013 at 2:13 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> Dear Eliot, all
>> Am 24.09.2013 um 20:16 schrieb Eliot Miranda <eliot.miranda at 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
Yes. I should make a pause to emphasize this, too. mea culpa.
> 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.
Yes, I imagine. I was pretty excited, too, when he showed me that it works ;)
> 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
> # determine cygwin version using uname -r
> # determine "old" (eg 1.5.25(0.156/4/2)) or "new" cygwin (eg
> ifeq ($(shell ls
> ifdef NEWMGW
When I sat down with Marcel, we were at this point, too.
It turned out, however, that the i686-pc-mingw32-gcc was
not able to compile and link (or better, find the right paths
and includes) the whole codebase. Marcel found a package
providing an i686-w64-mingw32-gcc, which got further but
eventually failed, too.
> Ian apparently has done some tweaks to the build system
>> for the win32 branch. It also uses MSYS and MinGW but
>> probably more recent gcc'en (but I'm not sure).
>> 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.
well, the whole cygwinbuild dir is gone and replaced…
>> 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 :-(
If Marcel has a VM request again, and we have some time,
we probably can figure out something, but alas, I cannot
promis; university wants its time :)
>> I think Mariano did a good job for an introduction
>> to building a Squeak/Cog VM, But his 2nd-level
>> tool-chain (sources from gitorious+CMake via CMakeVMMaker)
>> 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 ;-)
We better should.
> 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 ;-)
Not cynic, but more pragmatic.
But I think we will eventually reach a status of discomfort with either
choices we face (think gcc3 vs gcc4 and so on) and then, we as a community
have to decide.
As for cmake vs autoconf vs…, when I worked on compiling the Self VM,
I looked into several build systems. They all have their odds and ends,
but in the end I figured, that they all need external tools apart from
make, and cross-platform make is really painful.
In the end I chose cmake because
• learning a new language is not worse than for automake/conf/tools,
gyp, or qmake (haven't looked at tup)
• CMake can generate files for your preferred native Build environment
(Xcode on OSX, VStudio on Win32, Eclipse…) and pure Makefiles, too.
• cmake allows for integration with pkg-config to detect availability
• cmake can be used with GUIs/CUIs to pre-select configuration schemes
(eg, shall I build a Cog/Stack/Interpreter? MT/non-MT? Pharo/Squeak-
branded? Newspeak instruction set?)
This is no advertising but my findings of that time.
Either choice will fit me.
 I wrote about my findings of that time on http://blog.selflanguage.org/
My CMake stuff for self went here: https://github.com/krono/self/tree/cmake/vm/cmake
I personally think the hodgepodge of autoconf syntax, automake syntax, and
loads of template files, and M4, make this choice as approachable as
the Mt Everest for a 5 year old
 See https://code.google.com/p/gyp/
Used by Chromium and v8 to overcome certain problems the authors had with cmake.
The syntax (https://code.google.com/p/gyp/wiki/GypLanguageSpecification) essentially
is JSON with special keyword (or s-expressions, if you want)
It bears resemblance with cmake but really makes only sense when using Qt.
 http://gittup.org/tup/ I don't know it but Chis Double (http://double.co.nz/,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130925/d5e585be/signature.pgp
More information about the Vm-dev