Patch by Martell Malone based on work done by ruben vb.
I have created a patch for clang that will find the include directories for the new windows-gnu triplet.
yaron.keren on Apr 18 2014, 1:38 AM.Authored by
Chandler, I''ve contacted Ruben to contribute as well.
David, I think Martell means that the driver needs to locate gcc and from this to find libstdc++ location.
Martell, on previous e-mail discussion on the lists it was suggested that the best way to do this is by locating gcc.exe on the PATH. This way, you could have several MinGW versions installed on the system, possibly in non standard locations and the correct one would be chosen. Correct one means the gcc you'd get if you run gcc from the command prompt. This also avoids hardcoded paths as today.
About the directories, it's worth supporting both MinGW-w64 and MinGW.org. Although personally I use and prefer the -w64 distribution we can't ignore MinGW.org is quite popular as well.
Running g++ -E -x c++ - -v < nul you can get the include directories.
I'm not sure the distribution could be reliably identified. If yes, we could add the distribution-specific includes. If not, we could add all include directories for both distributions and clang will prune the nonexisting ones. Note this will not work well if you have both disribtuions installed since all includes will be added.
I'm the original author of the patch, and hereby I officially contribute the code contained in this commit :-).
I understand the missing MinGW.org support code, this needs to be fixed, although IMHO that would classify as legacy support, as MinGW.org has been abandoned by all major Linux distro's, there is no support for 64-bit, nor any support for much of the newer Windows and DirectX APIs. But that is irrelevant to the discussion here.
The reason I chose for hardcoded paths is twofold:
The second point is far off future, as the GCC runtime libraries (and some startup code) are still linked at this point. This patch does away with any GCC executable dependencies, though.
By hardcoded paths I did not mean what's in the patch above which are relative-to-gcc-hardcoded, that's OK.
I fully agree with you regarding mingw.org vs -w64. If supporting mingw.org required more work than adding the several include paths I listed above I'd hesitate, but if it's trivial to support than why not. BTW, LLVM does have a mingw.org building bot.
Okay so I have looked at all the comments and I'm trying to get all the pieces together to get this working best as possible.
@rubenvb I first would like to thank you for allowing this patch to be included, :)
With you being the original author I'd like to poke your brain about a thing or two.
@yaron.kernen I have made a few inline comments with reference to the different questions posed.
@martell: Currently there is no functional libc++, so it makes little sense in coding up directory logic if that might still change between then and now. But if you feel you can write something future-proof in this regard, I won't stop you.
Martell, To submit an updated patch:
I marked the revision as editable by all users so I hope this will work. If you don't see D3240 in the attach to list then it's possible that only the author can submit the new diff. I didn't find answer to this on
In this case, either open a new revision and link to this one and I'll close it or email me the diff and I'll submit it.
Martell, I found the command to take the revision. It's called "Commandeer revision" in the Action pull-down box. I didn't see it before because I'm already the revision owner and can't take over the revision...
So, please Commandeer this revision and then you can follow the instructions in previous comment.
I seem to recall that you guys didn't want to use --sysroot to point to the mingw installation. The Generic_GCC toolchain respects a --gcc-toolchain= flag which could be used to select a mingw installation instead.
Sure, feel free to comandeer the revision or create a new one.
2014-09-09 16:25 GMT+03:00 Alexey Pavlov <firstname.lastname@example.org>: