[Gc] Win64 GCC support
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:
>> 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"
> 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