Re: [Gc] Win64 GCC support
ivmai at mail.ru
Fri Jun 19 03:40:52 PDT 2009
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.
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
> > 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.
More information about the Gc