Getting clang header search path

Clang Frontend
1

What is the clang command that shows me the header search path ?

I built the latest clang on Windows targeted at gcc using mingw64/gcc4.9.1 32-bit, which is in the PATH. But when I execute clang it is not finding the C++ header files.

2
3

Nope, it’s -v

4

Nope, it's -v

I do not think so:

C:\Programming\VersionControl\bninja_installed_clang\bin>clang++ -v
clang version 3.6.0 (215674)
Target: i686-pc-windows-gnu
Thread model: posix

C:\Programming\VersionControl\bninja_installed_clang\bin>clang -v
clang version 3.6.0 (215674)
Target: i686-pc-windows-gnu
Thread model: posix

C:\Programming\VersionControl\bninja_installed_clang\bin>clang++ -###
clang version 3.6.0 (215674)
Target: i686-pc-windows-gnu
Thread model: posix

C:\Programming\VersionControl\bninja_installed_clang\bin>clang -###
clang version 3.6.0 (215674)
Target: i686-pc-windows-gnu
Thread model: posix

None of these return the header search path.

5

-v does if you give it a file.

6

-v does if you give it a file.

What is the purpose of the 'file' that you pass to it ?

7

-v by itself just prints the version, I guess you need the frontend action to get the include paths.

8

In this case, the clang binary needs even just a cursory file name to get far enough into its logic to output the info you want. Since you seem to be in Windows, try the following (warning: I’m a Linux user and only know this because I googled it):

clang++ -E -v -### -x c++ NUL

If you’re using the powershell, I think you can substitute ‘$nul’ (no apostrophes) for NUL

9

I don't see the search path with -###.
The attached shows the output.

OTOH, using -v, as suggested in another thread:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038611.html

does show the headers.

HTH.

-regards,
Larry

triplehash.out (2.25 KB)

10

In this case, the clang binary needs even just a cursory file name to
get far enough into its logic to output the info you want. Since you
seem to be in Windows, try the following (warning: I'm a Linux user and
only know this because I googled it):

clang++ -E -v -### -x c++ NUL

Here is my output:

C:\Programming\VersionControl\bninja_installed_clang\bin>clang++ -E -v -### -x c
++ NUL
clang version 3.6.0 (215674)
Target: i686-pc-windows-gnu
Thread model: posix
"C:\\Programming\\VersionControl\\bninja_installed_clang\\bin\\clang++.exe" "-c
c1" "-triple" "i686-pc-windows-gnu" "-E" "-disable-free" "-disable-llvm-verifier
" "-main-file-name" "NUL" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fm
ath-errno" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "pentium4" "-v"
"-dwarf-column-info" "-resource-dir" "C:\\Programming\\VersionControl\\bninja_i
nstalled_clang\\bin\\..\\lib\\clang\\3.6.0" "-fdeprecated-macro" "-fdebug-compil
ation-dir" "C:\\Programming\\VersionControl\\bninja_installed_clang\\bin" "-ferr
or-limit" "19" "-fmessage-length" "80" "-mstackrealign" "-fno-use-cxa-atexit" "-
fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-o" "-" "-x" "c++" "NUL"

I do not see header path information anywhere.

11

clang version 3.6.0 (04f9ed5f8cf30195a85743d43e56d06f62b87ce2) (99cd10fe111560b9921e731a89109972a149dfab)

12

Bingo ! That gives me the output I expected.

But it is looking in all sorts of non-existent directories related to gcc versions 4.7.0 through 4.8.2, which of course don't exist since I used mingw64 gcc-4.9.1 32-bit to build clang. And therefore it does not find the C++ standard libraries of gcc-4.9.1.

I can switch to mingw gcc-4.8.1 and hopefully that will work after I rebuild the latest clang.

The moral of the story is that building clang from source on Windows targeting gcc will not work with gcc outside the 4.7.0 to 4.8.2 range. I wish such simple things were documented somewhere in clang documentation.

Did I miss it ? Is there any clang table which specifies which clang versions depend on which gcc version ranges ?

13

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.

14

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. 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. 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.

15

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

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.
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]

16

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.

17

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.

My output from clang++ -E -v -x c++ NUL shows that the search in the directory where gcc resides ( c:\mingw in my case ) only looks for versions based on the "n.n.n" format. In the clang directory it looks for headers based triplet string, but of course clang does not ship with its own C++ standard library headers but uses those of gcc.