I recently cloned llvm from git and did a build of clang on my Macbook
(OSX 10.14.6). I have Xcode (11.0) installed and built using Xcode's
included apple-clang. The build worked fine but when I went to compile
my project I got an error where it was trying to #include a stdlib
header file. I'm not really sure but I think this is because in MacOS
Mojave by default the os has System Integrity Protection enabled which
among other things prevents modification to at least some locations
under /usr (root user unable to ln -s ... /usr/include/c++, tried that).
So Xcode does not install or symlink the standard library headers into
/usr/include. apple-clang as installed already includes the installed
stdlib header directories in its search path. Looking at the current git
source I don't see a way to build clang to set a directory to look in
for the stdlib. I did try -DGCC_INSTALL_PREFIX=... and that did not do
the trick, apparently because it does not end up keeping that path for
searching include <...>.
I made a local git branch and made some changes to allow me to build a
clang++ that includes the installed location in the include search path
but before I log a bug/submit a change for review I wanted to see what
constraints around this would end up being acceptable. Should the cmake
scripts automatically pick this up by default on OSX if building with
the Xcode-supplied compiler? Should it be structured/would it be useful
to introduce a top-level #define to set this default stdlib search path
in clang/include/clang/Config/config.h.cmake?
For reference, here's a comparison on a test.cpp file containing simple #include <string>:
Yeah it'd be great for it to work out of the box, the headers are
already there in the normal install of Xcode, so not like it's "missing"
some other component and it would be great to work out of the box. Based
on the (non-)responses I guess I won't know how receptive the project
will be until I submit a patch.
When building Clang the build system could run "xcrun --show-sdk-path" to identify the SDK path. Or to be even more flexible: when running Clang it could run the above code and it will avoid the need for hard coding the path to the SDK.
Yeah, there are lots of ways it /could/ be solved but I guess what I'm
proposing is that if there exists a default SDK that goes with the
compiler you're using to build clang and we know about it, shouldn't we
be providing the mechanism internally to find it (only in the case where
it cannot be found in the obvious places eg. /usr/include)? In the
ordinary case (where it is installed in /usr/include) the compiler would
already pick it up, so it's not like we're injecting strange behavior
right? Or I'm crazy? I don't know, but ending up with a good compiler
that cannot find the std lib, even though the previous compiler did, is
just kicking the problem "upstream". It seems a reasonable minimal
requirement that running clang++ without extra include paths should be
able to find the standard library.
Regrettably it seems that others do not see this as a legitimate bug
:-(. I'm happy to create a ticket, but as a noob to cfe-dev I hit the
mailing list first to test the waters and the reaction didn't seem to
indicate that anyone else regarded it as something that needed fixing.
I'm with you though, I regard this as straight-up broken: ending up with
a compiler that doesn't know where it's standard library is may be a
valid compiler but not a generally useful one.
I just built clang from git master again and ran into this issue again. Jens, did you ever create a ticket? I'd like to CC myself. Otherwise I can write one up.
I’m happy to get a patch into acceptable shape that would fix it, but it seemed like the initial response felt more like WONTFIX. Did someone else create a ticket?
That fixed it eh? Hmmmm, strange. The only change seems to be that it appends sysroot for seach paths that are not specified as absolute paths. Maybe something else fixed it? I’ll have to pull clean source and give it a try.
I just rebuilt from git master (without the patch) on macOS 10.13.6 and the resulting clang still can't find the STL headers. Then I rebuilt with the patch, and it finds the headers. So nothing seems fixed to me.
Nothing else I found online worked either.