[cfe-dev] Getting clang header search path
eldlistmailingz at tropicsoft.com
Sun Aug 17 06:26:38 PDT 2014
On 8/16/2014 2:07 PM, Larry Evans wrote:
> 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:
>> Now, the example in that post just showed:
>> 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
> 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.
>>> 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.
More information about the cfe-dev