3

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
Shazamo Morebucks
  • 478
  • 1
  • 8
  • 19
  • The compiler find the header file `~/SDKs/Clang+LLVM10/bin/../include/c++/v1/string.h` just fine, it's when that file does `#include_next ` (note that it's not the standard `#include` directive) that it can't find a supposedly other `` header file. – Some programmer dude Apr 20 '20 at 11:27
  • 1
    Thanks for your comment, what can I do to fix this error? – Shazamo Morebucks Apr 20 '20 at 11:34

1 Answers1

10

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.

Karl.Deng
  • 116
  • 2
  • 4