[Gc] Win64 GCC support

NightStrike nightstrike at gmail.com
Mon Jun 22 07:09:44 PDT 2009


On Sun, Jun 21, 2009 at 11:23 AM, Petter Urkedal<urkedal at nbi.dk> wrote:
> On 2009-06-21, Ivan Maidanski wrote:
>> Hi!
>>
>> NightStrike <nightstrike at gmail.com> wrote:
>> > 2009/6/21 Ivan Maidanski <ivmai at mail.ru>:
>> > > Hi!
>> > >
>> > > NightStrike <nightstrike at gmail.com> wrote:
>> > >> On Sun, Jun 21, 2009 at 3:00 AM, Petter Urkedal<urkedal at nbi.dk> wrote:
>> > >> > On 2009-06-20, NightStrike wrote:
>> > >> >> 2009/6/19 Ivan Maidanski <ivmai at mail.ru>:
>> > >> >> > I guess current configure won't work for mingw-w64.
>> > >> >> >
>> > >> >> > ...
>> > >> > Your seem to be familiar with Automake, so you probably know what to
>> > >> ....
>> > >> I can do the work, as it should be very easy.  It's just that I want
>> > >> to be clear how you guys want it done.  Going the AC_DEFINE route is
>> > >> handling it all at configure time instead of make time.  Both work
>> > >> fine, just tell me which to do and I'll do it.
>> > >
>> > > If I understood correctly the question, we handling it at configure time (as we pass the desired --enable/disable-XXX to configure).
>> >
>> > Well, nothing's being enabled or disabled.  It's more like;
>> >
>> > AS_CASE([$host],
>> >   [x86_64-w64-mingw*],[AC_DEFINE([GC_NOT_DLL])])
>> >
>> > Putting that in configure.ac will create a new #define GC_NOT_DLL when
>> > the host is mingw-w64's win64 host crt.
>> >
>> > Doing it at make time would involve setting the AM_CFLAGS variable in
>> > Makefile.am based on some condition.  Either one works.  In fact, you
>> > can commit those two lines there to configure.ac right now and
>> > regenerate it if you want.
>>
>> As we are not using config.h for now (although there's a suggestion to optionally use it (but only at build time, not public gc.h)). So, the preferred way, for now, is to set the AM_CFLAGS.
>
> No, AM_CFLAGS is not meant for configuration macros.  As NightStrike

AM_CFLAGS is for CFLAGS that are common to the whole Makefile.
Setting various -D options conditionally in AM_CFLAGS is definitely an
ok thing to do.

> hinted at in his question (which I missed), the AC_DEFINE macros ends up
> in $(DEFS), which in turn ends up on the compiler command line.  If/when
> my patch to use a config.h header is accepted, then the same macros ends
> up in that file and $(DEFS) becomes simply -DHAVE_CONFIG_H.  That means
> that if the source files start with
>
> #ifdef HAVE_CONFIG_H
> #  include "config.h"
> #endif
>
> then it's possible to switch between the two models without changes to
> the codebase other than the AC_CONFIG_HEADER invocation.
>
> The policy question is rather whether to use AC_DEFINE or to place the
> macro definition directly into header files under an
> architecture-dependent conditional.

Can you guys agree to the bikeshed's color quickly?  Any way will
work, and will be forwards-maintainable.  Who's the guy that has to
rubber stamp this?

I'm not trying to sound impatient.  It's just that this is backing up
a lot of changes in other projects.  We still need to get all of
upstream boehm merged down into the GCC tree.  I provided a two-line
fix that will work with any recent autoconf (you won't be able to use
2.53 anymore, but then again, I doubt you can do that anyway what with
your AC_INIT line and many other macros).  That's one solution, and
there are several more.  I personally don't care how it's done, I just
need it done.



More information about the Gc mailing list