[Gc] Win64 GCC support

NightStrike nightstrike at gmail.com
Sat Jun 20 11:45:56 PDT 2009


2009/6/19 Ivan Maidanski <ivmai at mail.ru>:
> Hi!
>
> NightStrike <nightstrike at gmail.com> wrote:
>> 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.
>>
>> /home/nightstrike/build/gcc-svn/gcc/boehm-gc/configure
>>  --cache-file=./config.cache
>> ...
>>  --target=x86_64-w64-mingw32
>>  --srcdir=../../../gcc/boehm-gc
>>
>
> No, not for configure but gcc itself (i.e. which -D options are passed).
>
> I guess current configure won't work for mingw-w64.
>
> The problem (You are seeing) with malloc.x is:
> 1. mingw-w64 defines _DLL (same as VC++ but not MinGW),
> 2. configure should supply -DGC_NOT_DLL (but don't),
> 3. gc_config_macros.h defines GC_API as dll_import (as _DLL present but no GC_BUILD and no GC_NOT_DLL),
> 4. GC_arrays is semi-private (as used by test) and tagged with GC_API,
> 5. you get "initializer element is not const" error (is this because of .rel.ro missing on Win32?)
>
> Are there any volunteers to get configure up-to-date and working on GNU/Win32 systems?

You guys are using automake, so it should be very easy to do this.
Unfortunately, it appears to be an old version of automake, one that
I've never even used before.  Are you averse to stepping up to a more
recent version?  1.11 is current.

>> >> > 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).
>
> I've occasionally fetch the latest but for 32-bit target (instead of 64-bit) and test with it:
> -m64, of course, results in unknown "DI" mode (BTW, why are you separating 32/64-bit builds?);
> _M_IX86 is incorrectly defined in _mingw.h.
>
> With a work around for _M_IX86, BDWGC works ok (on 32-bit for now). I'll check 64-bit later (but I guess no more surprises).

I believe Kai addressed your open bugs.  Does that fix everything?

>> > 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?
>
> Not in the non-GNU and non-Unix world.
>
> More over, gc.h is a public header and we shouldn't force the users including it to have configure (or config.h).
>
>>
>> > 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.
>
> Of course, I could add include inttype/stdint.h (guarded with GC_HAVE_INTTYPES/STDINT_H) and use [u]intptr_t (guarded with _INTPTR_T_DEFINED or so). This would be backward-compat and config-less.
> I wonder what Hans (the project owner) is thinking of it.

Whatever works :)



More information about the Gc mailing list