[cfe-dev] Getting clang header search path

[Edward Diener]

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

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