[cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h

Ruben Van Boxem vanboxem.ruben at gmail.com
Sat Jul 2 06:08:03 PDT 2011


2011/6/27 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" <dgregor at apple.com> het volgende:
>>
>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote:
>>
>>> Hi,
>>>
>>> I bring fixes for MinGW(-w64) Clang users:
>>>
>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to
>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this,
>>> seems only logical to have it here) and use ResourceDir to find the
>>> sysroot of where Clang.exe is located. From there, add the
>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++.
>>> All mingw-w64 toolchains are built --with-sysroot, and thus
>>> relocatable, so this change will always find the accompanying headers.
>>
>> I've committed this part as r133911.
>>
>>> 2. float.h: MinGW needs an #include_next, because as described on this
>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are
>>> non-standard extensions to float.h which are expected on Windows, and
>>> MinGW provides these declarations in their system header. GCC's
>>> float.h is "fixinclude"d to include_next the system header. Note that
>>> a trivial change is needed in mingw-w64's float.h, and that change
>>> will be committed as soon as Clang's header does what it's supposed to
>>> do.
>>
>>
>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed).
>
> I just copied that behavior (and the comment) from <stdint.h>, but I
> know that mingw-w64's float.h header does #undef everything it
> redefines, so it would perhaps be better if the #include_next in
> Clang's float.h came at the end. Then nothing else needs to change
> much.
>
> Ruben
>

I have attached a new patch with two new GCC versions for the include
paths, and I moved the #include_next <float.h> to the end. My previous
testing proved this would work if the mingw-w64 headers is adapted to
detect Clang as well (will happen as soon as Clang's header is
patched). If someone would be so kind to apply these minor changes,
I'd be very happy.

Thanks!

Ruben

PS: And once these changes are in, you can expect a CLang package to
be provided by me here for use with mingw-w64:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mingw.patch
Type: application/octet-stream
Size: 1089 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110702/8da0fb83/attachment.obj>


More information about the cfe-dev mailing list