Libtool search path on MacOS

This is a continuation of, which I could not reply to because I wasn’t actually subscribed to the list. My apologies.

But when I build it on MacOS, it doesn’t find any gcc installation (though I do
have it installed with homebrew). Since I’m building out-of-tree, the
“…/lib/clang/x.y.z/include” path is invalid. So the tool cannot locate
C/C++ header files. My current workaround is to use the C_INCLUDE_PATH
and CPLUS_INCLUDE_PATH environment variables to point to my C/C++
installations. Is there a better way of doing this on Mac?

I don’t think that homebrew installs anything in any of the default
paths. I would recommend installing Xcode and the command line tools. Or
alternatively only the command line tools.

I had already installed Xcode and the command line tools, but I don’t see how this would help.


Well, if you don't have Xcode and the command line tools installed there wouldn't be a GCC/Clang installation to find (I don't think it would be able to find the one in homebrew). But if you already have that installed, then unfortunately, I don't know.

Although I'm not sure if you're talking about the C/C++ standard library headers or the internal compiler headers. The former should be found in the standard include paths, /usr/include. The latter are only search for in the relative include path, ../lib/clang/x.y.z/include, in my experience.

In my tool [1] I solved that by embedding the internal headers in the executable [2][3].

[1] GitHub - jacob-carlborg/dstep: A tool for converting C and Objective-C headers to D modules



Sorry, I should have clarified. The C/C++ headers are the ones which cannot be found. For clarity, here’s the output of my tool with the -v flag (I’ve hidden some sensitive names with ***):

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
clang Invocation:
“clang-tool” “-cc1” “-triple” “x86_64-apple-macosx10.12.0” “-Wdeprecated-objc-isa-usage” “-Werror=deprecated-objc-isa-usage” “-fsyntax-only” “-disable-free” “-disable-llvm-verifier” “-discard-value-names” “-main-file-name” “AddressOfTest.cpp” “-mrelocation-model” “pic” “-pic-level” “2” “-mthread-model” “posix” “-mdisable-fp-elim” “-masm-verbose” “-munwind-tables” “-target-cpu” “penryn” “-target-linker-version” “278.4” “-v” “-dwarf-column-info” “-debugger-tuning=lldb” “-resource-dir” “/build-debug/bin/…/lib/clang/4.0.0" “-c-isystem” “/usr/local/include” “-stdlib=libc++” “-fdeprecated-macro” “-fdebug-compilation-dir” "/build-debug” “-ferror-limit” “19” “-fmessage-length” “95” “-stack-protector” “1” “-fblocks” “-fobjc-runtime=macosx-10.12.0” “-fencode-extended-block-signature” “-fcxx-exceptions” “-fexceptions” “-fmax-type-align=16” “-fdiagnostics-show-option” “-fcolor-diagnostics” “-x” “c++” “test.cpp”
clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-apple-darwin16.6.0
ignoring nonexistent directory “//build-debug/bin/…/include/c++/v1"
ignoring nonexistent directory “/usr/include/c++/v1”
ignoring nonexistent directory "
#include “…” search starts here:
#include <…> search starts here:
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.

Both my Xcode clang and my homebrew-installed clang find the headers through the relative path “…/include/c++/v1”. This won’t be possible with my libtool unless (a) I move my libtool into the directory where clang is installed, or (b) I also distribute the C/C++ headers with my libtool. Both of these solutions is ugly, so I would prefer something nicer.



If only Xcode is installed the headers are available at:



This can be verified by running "clang -E - -v < /dev/null". You'll see the above two paths (or something similar depending on which version of Xcode) are two of the paths Clang will search in.

If the command line tools are installed as well, the headers will be available in "/usr/include" as well. As you can see with the above command, "/usr/include" is one of the paths Clang will search in.

As can be seen in the output from your tool, the paths in /Applications/ are not searched in. Since it doesn't find the headers I suspect you don't have the command line tools installed.

Note that even though you can invoke "clang" on the command line to compile code, it doesn't necessarily mean that the command line tools are installed. You can install the command line tools by running "xcode-select --instal". If they're already installed, you'll get a message.

All this trouble with these paths are due to, I believe, Apple wants the Xcode app bundle to be completely self contained and not install anything outside of it unless the user explicitly asks for it. I'm guessing this it to be compatible with the App Store.

Hmmm. I have the same issue as this gentleman: I do have Xcode CLI tools installed, but it has installed an older version of libc++ in my /usr/include. The installed directory is /usr/include/c++/4.2.1 (I think this is either C++03 or C++98), but my libtool expects /usr/include/c++/v1. So is this actually an unresolved issue with Xcode?


Hmm, that's interesting. c++/4.2.1 is the old libstdc++ and c++/v1 is the new libc++, IIRC.

I'm not sure how it should behave. I noticed that if I add the "-stdlib=libstdc++" flag it will look in the "/usr/include/c++/4.2.1" directory instead of "/usr/include/c++/v1".

I just found the rest of the thread here: The upshot is that C++ headers are no longer installed to /usr/include on MacOS. When you install the Xcode command-line tools, the C++ headers are stored in /Library/Developer/CommandLineTools/usr/include/c++/v1. So libtools built on MacOS should look here instead of /usr/include/c++/v1. How can this be done?

I'm not that familiar with libtools, I've only used the C API in libclang. In libclang you call the clang_parseTranslationUnit function and pass in the command line arguments that were passed to your application. It's possible to add an additional include search path before calling clang_parseTranslationUnit by adding ["-I", "/Library/Developer/CommandLineTools/usr/include/c++/v1"] to the command line arguments array. I'm not sure it's possible to do the same using libtools.

Your workaround should work, but it shouldn’t be this difficult.

Take a look at, lines 456-479. Since OSX 10.9, /usr/include/c++/v1 just doesn’t exist. Clang should instead use /Library/Developer/CommandLineTools/usr/include/c++/v1 and/or the XCode .app for libc++. Unless anyone disagrees, I’m going to file this as a bug report.

Your workaround should work, but it shouldn't be this difficult.

I agree.

Unless anyone disagrees, I'm going to file this as abug report.

Please do.