On Thu, Jul 22, 2010 at 9:59 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Thu, Jul 22, 2010 at 11:55 AM, Geoffroy Couprie geo.couprie@gmail.comwrote:
On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
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.dewrote:
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.
Well, now, g++ produces working binaries.
- 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.
Sorry, I was confusing with something else. We redefined the symbols too.