[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-users] [Mingw-cross-env-list] Re: [patch] [ginclude] coopera

From: Doug Semler
Subject: Re: [Mingw-users] [Mingw-cross-env-list] Re: [patch] [ginclude] cooperation between gcc's and mingw's float.h
Date: Sun, 20 Jun 2010 09:27:16 -0400

On Sun, Jun 20, 2010 at 8:00 AM, Paolo Bonzini <address@hidden> wrote:
> On 06/20/2010 01:50 PM, Volker Grabsch wrote:
>> Paolo Bonzini<address@hidden>  schrieb:
>>> On 06/19/2010 04:23 PM, Manuel López-Ibáñez wrote:
>>>> On 9 June 2010 13:59, Chris Sutcliffe<address@hidden>   wrote:
>>>>> On 7 June 2010 13:10, Volker Grabsch wrote:
>>>>>> To the GCC maintainers: Would you accept the patch if MinGW-RT
>>>>>>                         includes the other patch?
>>>> Perhaps the decision takers for this patch have not been specified
>>>> with sufficient clarity. It seems a build issue, so CCing a build
>>>> maintainer.
>>> What patch?  Archive link, please. :)
>> Start of discussion in the GCC mailing list:
>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00387.html
>> Start of discussion in the MinGW bugtracker:
>> http://sourceforge.net/tracker/?func=detail&atid=302435&aid=3011968&group_id=2435
>> Corresponding changeset in Mingw-cross-env:
>> http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/682d860fa4e9
> This is not really a GCC build machinery patch (more of a C front-end patch,
> or something like that), so I wouldn't approve it.  However, to understand
> the issue better, is there a place where I can see the full MinGW float.h?
> It seems to me like a better way to fix this might be to rely on
> fixincludes.

Mingw 64's float.h adds extensions to float.h for MS compatibility.  I
don't know about float.h from mingw.org but I believe it's similar
Unfortunately the fixincludes route doesn't work, because GCC's
float.h is included first, before the fixincludes headers so you run
into the exact same issue --- the runtime's float.h isn't ever

So, either USER_H needs to be overriden in the gcc config/i386/t-*
makefile frags to prevent gcc from installing the float.h header, so
that mingw's float.h is used, or gcc's float.h needs to be changed so
that it include_next's mingw's float.h.  There is a third messy
method, which is employed by gcc's stdint.h header which does some
things based on the target.  (there is one more method, below).

The drawback to the USER_H method is the requirement that the runtime
maintain a copy of float.h that is pretty a copy of gcc's.  That leads
to one licensing issue that I can think of, and that is that the
runtime may only be compiled by gcc itself...and it also requires the
runtime to track the header for changes.  I vaguely recall that idea
being discussed at one point...

The only other method (mentioned above) that I can really think of
would be a hack to the CPP specs to -include _mingw.h, which would say
have the file included always, and then have that file include the
mingw specific extensions.  That seems to me to be a nasty hack,

(Note that for mingw-64, this issue is also in stddef.h and stdarg.h.
However, stddef.h actually should probably have mingw-64's changes
incorporated into gcc's stddef.h since they are type sizing and
declarations that are specific for the architecture, like wint_t being
unsigned short not unsigned int, etc)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]