6

After updating to macOS Mojave, the the OS fails to search for headers in /usr/local/include when compiling with clang++ (from the command-line, i.e. outside Xcode). Note that /usr/local/include is for my system the default paths in which CMake installs the headers, it thus feels quite strange of having to manually include this.

Incidentally I have also performed a clean install, resulting in the same problem. In the latter I have, in the following order:

  1. Installed Xcode from the App-store.
  2. Ran xcode-select --install.

The problem appears to be similar as in this question where it is suggested to:

  • Run xcode-select --install. This obviously does not solve the problem. Insisting on this by rerunning the install command results in error: command line tools are already installed.
  • Then there is the suggestion to check the output of xcode-select -p. It should apparently read /Library/Developer/CommandLineTools, not /Applications/Xcode.app/Contents/Developer as in my case. The suggestion is to "delete [sic] Xcode from the Applications directory", which seems to be a bit brutal.

How to solve this?

Tom de Geus
  • 5,625
  • 2
  • 33
  • 77
  • Just add `/usr/local/include` to `HEADER_SEARCH_PATHS` in your build settings. – Paul R Sep 26 '18 at 14:01
  • @PaulR Thanks for the suggestion, but it appears to act on builds from Xcode if I'm right. I am specifically not referring to this, I use `clang++` outside of Xcode (I've edited my question to make this point more clear). – Tom de Geus Sep 26 '18 at 14:06
  • You can point `xcode-select` to another location, like so: `sudo xcode-select --switch /Library/Developer/CommandLineTools`. – AlexDenisov Sep 26 '18 at 14:33
  • 1
    @AlexDenisov Thanks, I will try. It remains unclear to me what the difference is between Xcode and Xcode's command-line-tools, why they seem to be not fully compatible, why they are in two locations, and what I break by choose the one or the other? – Tom de Geus Sep 26 '18 at 14:45
  • 1
    @TomdeGeus: OK - sorry - I missed that part. You could do the equivalent though, either on your command line or in a makefile, i.e. `-I/usr/include`. Note that this scenario is quite common on Linux and other platforms, where the gcc configuration determines which paths will be searched by default, and this may or may not include `/usr/local/include`. – Paul R Sep 26 '18 at 15:26
  • 2
    @PaulR As I've put in my edit `/usr/local/include` is CMake's default installation folder. So I think that it should be fair to consider this a system path. In that scenario I would expect that I should not have to work-around by `-I/usr/local/include`. I am however also not sure if this should be considered a bug. There might be a subtlety between Xcode and Xcode's command-line tools that I am overlooking? In any case, this problem did not exist in any of my previous installation. – Tom de Geus Sep 26 '18 at 15:57
  • 1
    I just installed Mojave and Xcode 10 last night and so I did a quick test with a command line clang++ compile, and it seems to have no problem with headers in /usr/local/include, so it looks like there is something wrong with your installation. (BTW, I know you're not using Xcode as such but did you launch Xcode 10 at least once and let it install its additional components ?) – Paul R Sep 27 '18 at 13:29
  • @PaulR Hmm. Yes I have opened it at least once, but I do not remember if I was prompted to install additional components. I your case, what is the output of `xcode-select -p`? – Tom de Geus Sep 28 '18 at 06:44
  • I get `/Applications/Xcode.app/Contents/Developer` – Paul R Sep 28 '18 at 06:58
  • FYI, `cmake` seems to [automagically add the `-isysroot` flag](https://stackoverflow.com/a/54103956/3196753) (which fixes the headers but causes some linking problems). – tresf Jan 09 '19 at 06:03

0 Answers0