[cfe-dev] Getting clang header search path
eldlistmailingz at tropicsoft.com
Sat Aug 16 04:03:52 PDT 2014
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. 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.
> On Sat, Aug 16, 2014 at 11:12 AM, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
> On 8/15/2014 10:23 AM, Craig Tenenbaum wrote:
> On Fri, Aug 15, 2014 at 9:28 AM, Edward Diener
> <eldlistmailingz at tropicsoft.__com
> <mailto:eldlistmailingz at tropicsoft.com>
> <mailto:eldlistmailingz at __tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>>>
> Here is my output:
> -E -v -### -x c
> ++ NUL
> clang version 3.6.0 (215674)
> Target: i686-pc-windows-gnu
> Thread model: posix
> c1" "-triple" "i686-pc-windows-gnu" "-E" "-disable-free"
> " "-main-file-name" "NUL" "-mrelocation-model" "static"
> "-mdisable-fp-elim" "-fm
> ath-errno" "-masm-verbose" "-mconstructor-aliases"
> "pentium4" "-v"
> "-dwarf-column-info" "-resource-dir"
> "-fdeprecated-macro" "-fdebug-compil
> or-limit" "19" "-fmessage-length" "80" "-mstackrealign"
> "-fno-use-cxa-atexit" "-
> fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions"
> "-fcolor-diagnostics" "-o" "-" "-x" "c++" "NUL"
> I do not see header path information anywhere.
> Sorry, my bad, try: clang++ -E -v -x c++ NUL
> 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
> Did I miss it ? Is there any clang table which specifies which clang
> versions depend on which gcc version ranges ?
More information about the cfe-dev