[Gc] Win64 GCC support
nightstrike at gmail.com
Thu Jun 18 20:47:55 PDT 2009
2009/6/18 Ivan Maidanski <ivmai at mail.ru>:
>> > The build scripts may be not up to date (this is out of my scope).
>> > I'm personally using these options:
>> > -O2 -fno-strict-aliasing -Wall -DALL_INTERIOR_POINTERS -DGC_GCJ_SUPPORT -DNO_DEBUGGING -DGC_NOT_DLL -DLARGE_CONFIG -DUSE_MUNMAP -DGC_THREADS -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -DNDEBUG -I include -I libatomic_ops-1.2\src
>> > ...
>> I'm using configure, with host=x86_64-w64-mingw32 and no other
>> options. I'm cross compiling from linux to win64. This is the same
>> way that gcc will build it in-tree once we merge everything back over
>> (hopefully soon).
> It's better You provide the options gcc is executed with.
>> > My mingw build is: mingw-w64-bin_i686-mingw_20090420.
>> That's way old. Can you try the latest?
> Ok. I'll use the latest one (but for mingw i686 devel host).
You can hang out in irc://irc.oftc.net/#mingw-w64 if you want. We're
>> >> > The type you want is intptr_t from inttypes.h
>> Wouldn't it be better to special case out the oddball ancient systems
>> and use intptr_t elsewhere? There's an autoconf test just for this
>> purpose, AC_TYPE_INTPTR_T. It might be worth looking into.
> VC++ 2008 is not ancient but lacks inttypes.h (but intptr_t is present since 2003, I guess (guarded with _INTPTR_T_DEFINED)).
> And, AFAIK, it's typically defined in stdint.h (not inttypes.h).
inttypes includes stdint
> The idea with autoconf isn't good as config.h is not used in bdwgc (unlike gcc boehm-gc), not only for public gc.h but in the whole project.
You still use configure, though, right?
> Ok. I'll think about [u]intptr_t... (this, in fact, matters only for non-Windows LLP64 systems but I've never heard these are supported by GC, so this question is of little practical importance).
This is probably not the biggest of worries for us. How portable your
stuff is doesn't matter to us as long as you support Win64. So if you
guys don't care, or if you prefer your own way, then that's cool.
> Also, as I can see, gcj is not under development for 2 years.
We've had bigger obstacles :)
More information about the Gc