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.
2. float.h: MinGW needs an #include_next, because as described on this
page (Math and floating-point support | Microsoft Docs) 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.
I do not have commit access, so if someone would please commit these
changes, Clang will become a nicer MinGW compiler, and I would very
much appreciate it. There are still lots of problems though, but this
will make a basic setup work at least for trivial programs.
Thanks!
Ruben
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 (Math and floating-point support | Microsoft Learn) 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).
- Doug
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:
mingw.patch (1.06 KB)
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 (Math and floating-point support | Microsoft Learn) 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.
My suggestion would have been to #include_next <float.h> at the beginning, then #undef everything that Clang's <float.h> is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work?
The patch you attached is something different (a CMake change for TableGen). Is that change still necessary?
- Doug
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 (Math and floating-point support | Microsoft Learn) 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.
My suggestion would have been to #include_next <float.h> at the beginning, then #undef everything that Clang's <float.h> is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work?
It does, I just tested it. Attached is your change.
The patch you attached is something different (a CMake change for TableGen). Is that change still necessary?
Yes, terribly sorry for the bad attachment, I took the LLVM directory
instead of LLVM/tools/clang directory. Should have double-checked.
Ruben
mingw.patch (3.06 KB)
Sorry to be such a pain in the *ss, but I'd really like this patch in.
Then I can build/release a mingw-w64 Clang build and you'll have a lot
more testers for that platform (I hope).
Thanks!
Ruben
mingw.patch (3.06 KB)
It *is* a holiday weekend in the United States, where most of the code owners are located.
Committed as r134406 and r134407.
- Doug
So it is 
must have forgotten about that :s At least I know I'm a
pain in the *ss. Thanks *very* much!
Ruben
I just noticed the new float.h undef's everything twice if __MINGW32__
is defined. I assume it was the idea to remove the undef's outside of
the __MINGW32__ ifdef?
Please "svn revert" your float.h; I moved the undefs inside of the __MINGW32__ ifdef.
- Doug
I see, sorry for the noise.