[cfe-dev] Getting clang header search path

Larry Evans cppljevans at suddenlink.net
Sat Aug 16 11:07:25 PDT 2014

On 08/16/2014 12:44 PM, Larry Evans wrote:
> On 08/16/2014 06:03 AM, Edward Diener wrote:
>> On 8/15/2014 11:26 PM, Nikola Smiljanic wrote:
>>> Yeah this is one of those "known problems". MinGW never had a proper
>>> toolchain implemented, I think Ruben was working on this. Include paths
>>> come from hardcoded versions listed in InitHeaderSearch.cpp.
>> It looks like the C++ standard library location is different between the
>> MingW and MingW64 implementations.
>> In MingW the locations are:
>> C:\mingw\lib\gcc\mingw32\*gcc_version as n.n.n*\include\c++
>> C:\mingw\mingw32\lib\gcc\mingw32\*gcc_version as n.n.n*\include\c++
>> In MingW64 the locations is:
>> C:\mingw\*gcc_version as triplex as in i686-w64-mingw32*\include\c++
>> There is probably some way of telling the clang CMake based build how to
>> find the C++ standard library in the clang/llvm CMake options but I do
>> not know what it is. 
> Couldn't the CMake *scripts* be modified to just run g++ -v?  Then
> parse output looking for the C++ standard library headers?  Although the
> output with g++ -v shows all headers, you could run 1st with -nostdinc++
> and then without that flag and compare the two outputs, as shown here:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038611.html
> Now, the example in that post just showed:
>   usr/include/c++/v1
> but that may be because the -stdlib=libc++ was also passed.  OTOH,
> if the flag is left off, the the difference is:
> diff not.out yes.out
> 0a1,3
> /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0
> /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/x86_64-unknown-linux-gnu
> /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/backward

To be clear, I was suggesting that the script or program that
produces the above diff could be run from within the CMake
script and the output would then be used to set the
"hardcoded" paths used in InitHeaderSearch.cpp.

>> The closes things I see are
>> COMPILER_RT_TEST_TARGET_TRIPLE, described as "Default triple for
>> cross-compiled executables" and LLVM_DEFAULT_TARGET_TRIPLE described as
>> "Default target for which LLVM will generate code". But neither of these
>> triple sequences show up when I view the clang header search.
>> It appears that clang only looks for the headers following the MingW
>> *gcc_version as n.n.n* sequence when looking in the gcc location for its
>> C++ standard library.
>> I will switch from MingW64 to MingW for gcc on Windows when using clang,
>> but it sure would be nice if clang understood the MingW64 location also.

I just had a brief look at the InitHeaderSearch.cpp which Nikola
mentioned, and it includes:

  /// AddMinGW64CXXPaths - Add the necessary paths to support
  /// libstdc++ of x86_64-w64-mingw32 aka mingw-w64.
  void AddMinGW64CXXPaths(StringRef Base,
                          StringRef Version);

which, based on the comments, I would guess it should work on MingW64.
But apparently it does not, for some reason.

>> Also the latest clang needs to be updated for gcc versions above 4.8.2
>> such as 4.8.3, 4.9.0, and 4.9.1.
> [snip]

More information about the cfe-dev mailing list