CODEWITHSUNDEEP
c++clang++include-pathstdmultiple-inclusions
Shazamo Morebucks
Shazamo Morebucks

Reputation: 50

Clang++ updated, can't find certain headers despite them being in the include directory

So I'm on mac and wanted to experiment with the latest llvm release, without having to wait for them to be passed on the xcode command line tools.

So I downloaded the LLVM 10 release pre-built binary from their downloads page, and stuck it in a folder called llvm. So the clang executable can be found in ~/SDKs/LLVM/bin.

I make this program:

#include <string>
#include <iostream>

int main(int argc, char const *argv[])
{
    std::string myString("Hello World");
    std::cout << myString;
    return 0;
}

and run:

~/SDKs/Clang+LLVM10/bin/clang++ main.cpp

I get this fatal error:

~/SDKs/Clang+LLVM10/bin/../include/c++/v1/string.h:60:15: fatal error: 
      'string.h' file not found
#include_next <string.h>
              ^~~~~~~~~~

Which doesn't make sense because I can find string.h manually using finder, and it's right there in the folder that is quoted in the error.

I'm guessing this has something to do with clang++ searching my system include path first, finding an older string.h there and so choosing not to use the updated string.h, causing an error?

Some additional info if it helps:

Running this (the new compiler)

~/Programming/SDKs/Clang+LLVM10/bin/clang++ -Wp,-v -E -xc -x c++ /dev/null

Gives me:

clang -cc1 version 10.0.0 based upon LLVM 10.0.0 default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 ~/SDKs/Clang+LLVM10/bin/../include/c++/v1
 /usr/local/include
 ~/SDKs/Clang+LLVM10/lib/clang/10.0.0/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 393 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2

Running (this is the default compiler with that comes with my mac)

clang++ -Wp,-v -E -xc -x c++ /dev/null

gives me

clang -cc1 version 11.0.0 (clang-1100.0.33.17) default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 374 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2

Upvotes: 3

Views: 6378

Answers (1)

Karl.Deng
Karl.Deng

Reputation: 116

I also encountered this error. And after my a digging out, I found the reason: The include_next is a gnu compiler extension, seems it does not exist in clang. Although clang(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++) has packaged the original std lib under directory: “ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/“, but as compile source codes from Apple Mac, generally it always specifies the system root path by option “-isysroot”, generally the command is like this:“-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk” , to overwrite the default std lib search path. So maybe you must overwrite the default sys root to ensure right std lib to be linked.

Upvotes: 10

Related Questions