Re[6]: [Gc] Win64 GCC support

Ivan Maidanski ivmai at mail.ru
Fri Jun 19 03:40:52 PDT 2009


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?

> >> > 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).

> 
> You can hang out in irc://irc.oftc.net/#mingw-w64 if you want.  We're
> always there.
> 
> >> >> > 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

Yes (C99).

> 
> > 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.

> ...

Bye.


More information about the Gc mailing list