On Thu, Jul 22, 2010 at 11:55 AM, Geoffroy Couprie <geo.couprie@gmail.com> wrote:

 

On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

 
Hi Geoffroy,

On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <geo.couprie@gmail.com> wrote:

 
Hello,

On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <andreas.raab@gmx.de> wrote:

On 7/22/2010 4:55 AM, David T. Lewis wrote:

On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:

But the more serious issue is that the configure in VMMaker is only suitable
for linux.  I guess that the right thing to do for FreeBSD is to run make in
platforms/unix/config to generate a FreeBSD-specific configure.  But I'm out
of my depth when it comes to autoconf.

Note that Ian moved to CMake for the unix builds, so autoconf is no longer
used for building from the SVN trunk. In addition, Geoffroy Couprie has
developed this further such that the VM can be built for both unix and
Windows targets, see thread here:

 http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html

It's up to Ian and Andreas to say if they want to pursue this direction,
but if you need the Cog build process to be more platform independent
this would be a good thing to consider.

Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.

* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.

 

MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.

What about C++ compilation?

I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken exception handling, and 4.4 works well.

The issue is that binaries produced with g++ -mno-cygwin -mwindows will not work because there is no support for them in the MS run-time.

 

* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.

At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.

 Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)

I think it would still need to be fixed though, but that's less work to do.

Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.

Yes.  Its just a matter of ifdeffing, and the differences can be localized.  There are differences anyway.  Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc.  Hence

#if _MSC_VER

# define LLFMT "I64d"

#else

# define LLFMT "lld"

#endif

Yes, THAT is really annoying. We encountered a lot of problems with 32/64 code and format specifiers in vlc, but switching to gcc 4.4 fixed them.

How does 4.4 fix the issue?  Remember we're talking about -mno-cygwin -mwindows because under that environment there's no GPL issue.