103

There's a previous question Can't compile C program on a Mac after upgrade to Mojave, and the answers to that have covered most of the variations on what goes wrong.

Now — as of Monday 2019-10-07 — you can upgrade to macOS Catalina 10.15. Once again, during the upgrade, the /usr/include directory has been blown away by the update, even though XCode 11.0 was installed before upgrading (from Mojave 10.14.6) to Catalina. Consequently, compilers built to expect that there is a /usr/include directory do not work any longer.

The main recommended step for the Mojave issues — using the command:

open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

does not work out of the gate because the directory /Library/Developer/CommandLineTools/Packages/ does not exist (so there's not yet a .pkg file to open).

Is there a good (official) way to create and populate the directory /usr/include?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • You do not need `/usr/include` to use Apple’s developer tools with Apple’s current Xcode. The headers and such are in `Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK`. (Keeping headers in different directories is necessary to support multiple target platforms, and it is good not to have a `/usr/include` to ensure that no compiles accidentally use files from it when targeting a version different from the host system.) What does `xcode-select -p` show for the path to the active developer directory? – Eric Postpischil Oct 07 '19 at 23:47
  • 1
    I built GCC 9.2.0 (on Mojave) and it expects to be able to use `/usr/include` for the system headers. I'd like to be able to use that still, though I suspect that Apple has finally thrown away the last vestiges of compatibility with legacy Unix systems (to some extent, the writing was on the wall with the system required to make Mojave 'work'). In which case, I probably have to rebuild GCC specifying the current location of the system headers somehow — manual bashing for how to configure GCC. – Jonathan Leffler Oct 07 '19 at 23:59
  • 2
    @JonathanLeffler: After the update to catalina I also face the problem that some files (like stdlib.h) are missing which are used by software package R when installing R packages. I tried the the same as you for macOS_10.14, but this is not possible anymore. GCC, c++ or whatever is installed in /Library/Developer/CommandLineTools/usr/bin, but R does not know. What can I do? – sebastiann Oct 12 '19 at 11:43
  • One way around the problem is to use the Xcode compilers — if they're installed, they know where to find the system headers. The CPATH technique in the accepted answer also seems to work OK. I've not yet suffered on a Mac from 'double typing' (that I know of). I've had my iPhone decide I've typed all sorts of interesting stuff, but so far, touch wood, my MacBook Pro has been OK. – Jonathan Leffler Oct 30 '19 at 04:38
  • 1
    The accepted answer got bash5.0 to compile, but now I'm running into problems with make and make install, which appear to be extremely similar `fatal error: wchar.h: No such file or directory # include compilation terminated`. I think they'll be a problem to take a look at tomorrow. Thanks for all your effort, it's been interesting and educational. – DryLabRebel Oct 30 '19 at 04:49

16 Answers16

77

Before you proceed, make sure to install xcode command line tools.

xcode-select --install

Actually, you can do it! Actually all the C headers are found here in this folder:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/

We just need to create symlink for all the headers file into this folder:

/usr/local/include/

It worked for me! the following command line will take care of all the problems:

sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

You will get some warning. Some of the headers already exists, like this:

ln: /usr/local/include//tcl.h: File exists
ln: /usr/local/include//tclDecls.h: File exists
ln: /usr/local/include//tclPlatDecls.h: File exists
ln: /usr/local/include//tclTomMath.h: File exists
ln: /usr/local/include//tclTomMathDecls.h: File exists
ln: /usr/local/include//tk.h: File exists
ln: /usr/local/include//tkDecls.h: File exists
ln: /usr/local/include//tkPlatDecls.h: File exists

totally ok to ignore. that's all.

Roy
  • 1,189
  • 7
  • 13
  • 2
    Yes, I suppose this is possible — thank you for the suggestion. It doesn't really match my requirements for 'system hygiene' (e.g. those duplicate headers) and the `/usr/local/` directory hierarchy is meant for local software rather than system software. IMO, the headers should be in `/usr/include` and Apple is just being a pain. – Jonathan Leffler Oct 12 '19 at 05:36
  • 2
    There is an way around, may work, you can try. In recovery mode, disable the SIP, then mount the `/` in write mode. Then Populate the `/usr/include` folder. It's because in 10.15, the System mounts as read only mode. without disabling the SIP, you won't be able to mount the System volume. – Roy Oct 12 '19 at 09:38
  • @KomolNathRoy: thanks for your hints. This worked for me very well. I could finally install all my wanted packages in the statistical software R, because no R finds everything it needs for installation. – sebastiann Oct 12 '19 at 17:48
  • 3
    Disabling the SIP is not acceptable to me, even as a temporary measure. – Jonathan Leffler Oct 13 '19 at 01:01
  • This is the only method that works for me. For some reason `macOS_SDK_headers_for_macOS_10.14` fails on my Mac 10.14.6. – Max Nov 04 '19 at 00:00
  • @Roy is there no way to symlink `/usr/include` to the system include directory? `ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ /usr/include` (I get an "Operation not permitted" error) – pooya13 Jan 27 '20 at 07:57
  • @pooya13 `/usr/include` is mounted by os in read only mode. No way to symlink this directory as far as I know. – Roy Jan 27 '20 at 14:42
  • 2
    this is the only method that worked, having tried half a dozen guides, +1 – trdavidson Feb 24 '20 at 16:51
  • Finally get ccls and lsp in emacs workings, on MAC OSX catalina – anquegi Feb 27 '20 at 20:19
  • 1
    The solution by @Roy did not work for me. In addition, it caused problems with Rcpp on Catalina. I rectified the problem as described here: ```https://stackoverflow.com/questions/64565863/rcpp-not-working-on-r-3-6-3-macos-catalina-10-15-7/64618049#64618049``` – Bob Nov 01 '20 at 20:43
  • First - you should be able to do what you need to do with the command line tools only. No need for a full Xcode installation. Second - hacking through SIP seems like a terrible approach. I feel it's more to do with environment variables, flags, and (perhaps) symlinks in the user account. – Brett Hale Aug 13 '21 at 07:28
  • any new solutions to this question ? such as OS-X upgrade to repopulate the `/usr/lib` and `/usr/include` directories ? XCode and Command Line Tools update on my Catalina deleted my `/usr/include` directory. Now both `-I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include` `-L/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib` need to be specified while compiling the code. `$DYLD_LIBRARY_PATH` doesn't even work in the current versions of Mac OSX. – Guddu Oct 31 '21 at 21:04
58

For me adding the following path to CPATH solved the issue:

export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Hamidreza Omidvar
  • 604
  • 5
  • 2
  • 3
    I tried adding the CPATH; however, I am still getting this same error. just trying to do a simple cout << "hello"; – Jon Pellant Oct 10 '19 at 18:52
  • 2
    When I tried this, it worked in a casual test with a GCC 9.2.0 built under Mojave using what's now Xcode 11.1 — thank you. – Jonathan Leffler Oct 11 '19 at 11:32
  • 17
    If you are using the command line tools instead of Xcode.app, use `export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/` – nalzok Oct 19 '19 at 05:49
  • ***One oddity*** — I've got some code which started `#include ` and then failed to compile complaining about: _`In file included from …/usr/include/sys/wait.h:110, —— from …/usr/include/stdlib.h:66, —— from bm.c:27: —— …/usr/include/sys/resource.h:443:9: error: no previous prototype for ‘getiopolicy_np’ [-Werror=missing-prototypes] —— 443 | int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);`_ —— Yet, when I add `#include ` before `#include `, it compiles OK. Still working out what this means and how to handle it automatically. – Jonathan Leffler Oct 30 '19 at 06:01
  • 1
    Another variant on this is: `#include ` — `#include ` — `int main(void) { printf("Hello World!\n"); return EXIT_SUCCESS; }`. With the headers in the sequence `` then ``, the code fails to compile; with the headers in the reverse sequence, the code compiles with no wittering. There is something weird about ``. (Compiler options: `gcc -O3 -g -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wcast-qual -Wstrict-prototypes -o trial-1 trial-1.c`) GCC is home-built 9.2.0. – Jonathan Leffler Oct 30 '19 at 06:11
  • When trying this fix for an iPhone SDK, i get "Unsupported architecture" as I guess that compiler only supports MacOS? Pointing to the iPhoneOS.platform folder is not working as I guess the ARM binaries cannot run on Mac. – bovesan Apr 23 '20 at 06:48
  • @nalzok is `SDKs/MacOSX10.15.sdk` more appropriate or `SDKs/MacOSX.sdk` ? thanks for your help. – Guddu Aug 03 '21 at 04:39
  • 1
    @Guddu I believe the latter is an alias to the former. Personally I prefer `SDKs/MacOSX.sdk` since it should always point to the latest SDK on each system upgrade. – nalzok Aug 03 '21 at 04:42
  • @nalzok, thanks unfortunately my problem did not go away https://stackoverflow.com/questions/68629681/gcc-stopped-working-after-xcode-reinstall – Guddu Aug 03 '21 at 04:49
35

TL;DR

It appears that Apple considers /usr/include as something that has gone the way of the dodo — it is extinct — or maybe it's like Monty Python's Parrot.

Using the Apple-provided GCC (actually, that's Clang by any other name, as the version information shows) or Clang avoids problems. Both /usr/bin/gcc and /usr/bin/clang will find the system libraries four directory levels below:

/Applications/Xcode.app/Contents/Developer/Platforms/…

If you build your own GCC or other compiler, you will (probably) need to configure it to find the system libraries under the Xcode application directory.

Explorations

Immediately after the upgrade, I ran XCode 11.0. It wanted to install some extra components, so I let it do so. However, that did not reinstate /usr/include or the directory under /Library.

One of the other bits of advice in the previous question was to run:

xcode-select --install

When doing so, it claimed that it downloaded the command line utilities, and it ensured that /usr/bin/gcc and /usr/bin/clang etc were present. That's a useful step (though I didn't definitively check whether they were present before).

$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$

Using /usr/bin/gcc, it is now possible to compile programs:

$ make CC=/usr/bin/gcc al
co  RCS/al.c,v al.c
RCS/al.c,v  -->  al.c
revision 1.7
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM   -o al al.c -L/Users/jleffler/lib/64  -ljl
$

However, /usr/include is still missing. There is a directory under /Library now:

$ ls /Library/Developer
CommandLineTools  PrivateFrameworks
$ ls /Library/Developer/CommandLineTools
Library SDKs    usr
$ ls /Library/Developer/CommandLineTools/SDKs
MacOSX.sdk      MacOSX10.14.sdk MacOSX10.15.sdk
$ ls /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$

Neither the System nor the Library directory contain anything very promising.

When all else fails, read the manual

Next step — find and read the release notes:

There's no information in there that relates to this. So, the probability is (AFAICS, after only an hour or two's effort) that Apple no longer support /usr/include — though it does still have a fully-loaded /usr/lib (no /lib though).

Time to check another compilation with GCC option -v added (in the makefile I used, setting UFLAGS adds the option to C compiler command line):

$ make UFLAGS=-v CC=/usr/bin/gcc ww
co  RCS/ww.c,v ww.c
RCS/ww.c,v  -->  ww.c
revision 4.9
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM -v  -o ww ww.c -L/Users/jleffler/lib/64  -ljl
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.15.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ww.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=10.15 -target-cpu penryn -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 512.4 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I /Users/jleffler/inc -D HAVE_MEMMEM -D HAVE_STRNDUP -D HAVE_STRNLEN -D HAVE_GETDELIM -I/usr/local/include -O3 -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -Wno-framework-include-private-from-public -Wno-atimport-in-framework-header -Wno-extra-semi-stmt -Wno-quoted-include-in-framework-header -pedantic -std=c11 -fdebug-compilation-dir /Users/jleffler/src/cmd -ferror-limit 19 -fmessage-length 110 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.15.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -x c ww.c
clang -cc1 version 11.0.0 (clang-1100.0.33.8) default target x86_64-apple-darwin19.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Users/jleffler/inc
 /usr/local/include
 /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
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.15.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ww -L/Users/jleffler/lib/64 /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -ljl -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil" -o ww.dSYM ww
$

The key information in that blizzard of data is:

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

That's effectively the 'root' directory for the compilation, so there should be sub-directories under that for usr and usr/include:

$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr
bin     include lib     libexec share
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
AppleTextureEncoder.h  dns_util.h             memory.h               simd
AssertMacros.h         dtrace.h               menu.h                 slapi-plugin.h
Availability.h         editline               miscfs                 spawn.h
AvailabilityInternal.h err.h                  module.modulemap       sqlite3.h
AvailabilityMacros.h   errno.h                monetary.h             sqlite3ext.h
AvailabilityVersions.h eti.h                  monitor.h              stab.h
…lots more lines…
dirent.h               mach-o                 security               xcselect.h
disktab.h              mach_debug             semaphore.h            xlocale
dispatch               machine                servers                xlocale.h
dlfcn.h                malloc                 setjmp.h               xpc
dns.h                  math.h                 sgtty.h                zconf.h
dns_sd.h               membership.h           signal.h               zlib.h
$

This shows that the mile-long and totally unmemorable directory name does contain the standard C and POSIX headers, plus Apple-specific extras.

The previous /usr/local/ directory appears to be intact; the warning about usr/local/include not existing under the -isysrootdir is harmless (and not visible without the -v option).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Sorry couldnt follow your suggestion. I am getting the same error with the catalina update. With vscode I couldnt build C++ apps and getting `wchar.h` not found error. I tried including this folder -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include and iam getting other errors like about missing symbols for "error: no member named 'isless' in the global namespace" – user3279954 Oct 10 '19 at 07:00
  • Enabled `--verbose` in the tasks file and noticed that vs code is looking at `/usr/include/c++/v1/` folder which no longer exist now in catalina. Added the following folder as well along with the above sdk include and now it works. "-I/Library/Developer/CommandLineTools/usr/include/c++/v1/", – user3279954 Oct 10 '19 at 07:26
  • 1
    @trojanfoe — I prefer SCCS but in 1999 it wasn’t clear whether SCCS was going to work sanely post-Y2K (and there wasn’t a good open source implementation of SCCS that I knew of), so I reluctantly switched to RCS. – Jonathan Leffler Oct 10 '19 at 13:05
  • Wow :D So anyway what's the issue with `/usr/include` going missing? It was always implicitly part of the compiler include path so the user never needed to know about it (apart from when you were trying to find where something was declared). Clang does the same with its SDK path under `Xcode.app` so the net-effect is the same. – trojanfoe Oct 10 '19 at 13:06
  • 1
    If anyone is still running in to this after following the steps here, check if you have **llvm** installed via **homebrew** and try uninstalling it entirely. That solved it for me. – Nitza Oct 11 '19 at 02:27
  • 1
    @trojanfoe: one issue (my primary problem) with `/usr/include` gone AWOL is that if you have built your own GCC from source, it was probably compiled to find the system headers in `/usr/include` and therefore the compilations fail. I want to use the latest GCC as well as Clang. I'm happy to use Apple's Clang, but I'm not happy to use Apple's Clang masquerading as GCC — it's not the same as GCC. I've not yet worked out a recipe for building GCC with system headers relocated. (I think `--with-native-system-header-dir="${XCODE_HDR}"` is part of the answer; it isn't, however, the whole answer.) – Jonathan Leffler Oct 11 '19 at 09:54
  • Yup that is a problem building compilers that have to know about the implicit system include directory. One solution is to use the homebrew gcc (or see [how they build gcc](https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc@8.rb)). – trojanfoe Oct 11 '19 at 10:11
  • Thanks for the link. It looks as if they set `sysroot` to the directory under which you can find `usr/include` (a mile-long name) and then `--with-native-system-header-dir=/usr/include` — that's different from what I tried (and failed with). Sometime in the next month or two, I'll give this a whirl (I'm a bit busy at the moment — long story; won't bore you with the details). – Jonathan Leffler Oct 11 '19 at 11:28
  • using `CC=/usr/bin/gcc` in the make command did the trick for me – hmedia1 Nov 05 '19 at 13:40
  • 1
    @Nitza I struck gold with your comment! I had `llvm` installed from homebrew because I had `ccls` installed. I actually now use `clangd`, so these clang build problems went away after `brew uninstall llvm`. Thank you. – Steven Lu Nov 28 '20 at 21:29
13

Set the following implicit Make variables to point to where the headers are now located for Xcode Command Line Tools (Xcode CLI): 

export CFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

The -isysroot option updates the location of the root files away from the system root directory /.

So, this ensures that the common /usr/* files are found in their new place.

That is, the files at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk are now found. These files are: 

Entitlements.plist 
Library
SDKSettings.json
SDKSettings.plist
System
usr
coatless
  • 20,011
  • 13
  • 69
  • 84
  • In my makefiles (and most other makefiles I see), `CFLAGS` is a lot more complex than one single option — the `-isysroot` option would need to be 'in addition to' the other settings (lots of other settings). There may be a kernel of an idea here (pass the `-isysroot` option and the location under `/Library/Developer/…`), but it would need some polishing before it is ready for prime time. – Jonathan Leffler Oct 13 '19 at 01:00
  • 2
    @JonathanLeffler Using `export CFLAGS+=-isysroot ...` instead will work for that use case. This is the only solution that worked for me (on Mojave (10.14) with Catalina (10.15) SDK. I don't have the `.pkg` file everyone talks about even though my XCode and command line tools are up to date). – Norswap Dec 04 '19 at 14:09
  • @Norswap — there’s a huge difference between the use of `CFLAGS=…` and `CFLAGS+=…`. – Jonathan Leffler Dec 04 '19 at 14:11
  • 1
    @JonathanLeffler agreed. I've updated the answer to use `+=`. Thanks @Norswap. – coatless Dec 04 '19 at 16:20
  • 1
    Alternatively, I've figured out that setting `SDKROOT` to the same sdk value (`/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk`) will work as well for me! – Norswap Dec 05 '19 at 15:11
7

On MacOS Catalina 10.15.4, with Xcode Version 11.5 (11E608c) I also needed to update the library path in my .zshrc (the MacOSX.sdk paths are new):

export CPATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include'
export LIBRARY_PATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib'
AlDante
  • 336
  • 3
  • 8
6

I am a newbie with C++ compiler for R in OSX and I got the same issue that C++ could not find the header after OS was updated (missing math.h although it was there). I followed instructions from https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ but nothing changed.

Finally, it worked for me after I reinstalled the Xcode CLI

xcode-select --install

and then change the flags to Var as @Coatless suggested:

export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Nancy
  • 61
  • 3
5

If you have both the command line tools and XCode installed, make sure the SDK installed by the command line tools is actually being used:

#Check the current sdk

$ xcrun --show-sdk-path

#Change sdk

$ sudo xcode-select -s /Library/Developer/CommandLineTools #Using CommandLineTools SDK

$ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer #Using XCode.app SDK

kudos to https://stackoverflow.com/a/61526989/596599 for this answer.

PacificSky
  • 3,422
  • 2
  • 25
  • 24
4

For me, it works well as follow:

1. xcode-select --install

2. sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

3. export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
pfcstyle
  • 97
  • 5
3

In my case I seemed to have llvm and gcc also installed using homebrew. When I removed those, and thus relied fully on the macOS clang, it could find the headers and the compiling worked again.

frbl
  • 1,172
  • 11
  • 17
2

Short Answer

/Library/Developer/CommandLineTools/usr/bin/clang++ -o main main.cpp -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

The Result

Explanation

In current macOS version, the c/c++ headers are searched inside /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/, instead of /usr/include. So you need to 'reset' the root directory using -isysroot option.

Hope this makes sense .

UniverseFly
  • 49
  • 2
1

If using an external LLVM installation, add these to your ~/.bash_profile

LLVM_PATH="/usr/local/opt/llvm/" # or any other path
LLVM_VERSION="11.0.0"
export PATH="$LLVM_PATH:$PATH"
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LD_LIBRARY_PATH="$LLVM_PATH/lib/:$LD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH="$LLVM_PATH/lib/:$DYLD_LIBRARY_PATH"
export CPATH="$LLVM_PATH/lib/clang/$LLVM_VERSION/include/"
export LDFLAGS="-L$LLVM_PATH/lib"
export CPPFLAGS="-I$LLVM_PATH/include"
export CC="$LLVM_PATH/bin/clang"
export CXX="$LLVM_PATH/bin/clang++"

(adjust the clang version and the external llvm installation path.)

Then run source ~/.bash_profile

Amin Ya
  • 1,515
  • 1
  • 19
  • 30
0

apue.h dependency was still missing in my /usr/local/include after following Komol Nath Roy answer in this question.

I downloaded the dependency manually from git and placed it in /usr/local/include

Matthew Barbara
  • 3,792
  • 2
  • 21
  • 32
  • 1
    The header `apue.h` comes from W Richard Stevens, Stephen A Rago [Advanced Programming in the Unix Environment, 3rd Edn](https://smile.amazon.com/dp/0321637739) 2013. AFAIK, it was never provided by Apple as a system header. (It isn't in `/usr/include` on my machine that stills run Mojave.) If it was once installed in `/usr/include`, it was probably created manually rather than being provided by Apple. As such, it should have been installed in `/usr/local/include` previously. – Jonathan Leffler Oct 13 '19 at 14:58
  • Excuse my naive question but I just got my hands on C++ this week. Are dependencies/headers managed manually in c++? if yes, should I put all said dependecies/headers in `/usr/include`? – Matthew Barbara Oct 13 '19 at 15:14
  • 1
    Q1: More or less. It depends a bit on what you mean, but you have to worry about dependencies and headers for C or C++ if the headers are not standard on the machine(s) you're working with. Then comes the question — what's standard? And about the best answer that can be given is "it depends", and it depends on a lot of factors — including 'platform' (O/S, compiler). Q2 is "No, you should not usually put anything in `/usr/include`" — use `/usr/local/include` instead. Generally, it is safest to leave `/usr/include` and `/usr/lib` alone, and add material under `/usr/local` instead. – Jonathan Leffler Oct 13 '19 at 15:29
0

The solution was simpler than I thought. Install clang/llvm.

brew install llvm

Then we need to create symlinks ourselves.

for f in /usr/local/Cellar/llvm/9.0.0_1/bin/clang*; do ln -s ${f} /usr/local/bin/"${f##*/}"; done

And

ln -s /usr/local/Cellar/llvm/9.0.0_1/include/c++ /usr/local/include/c++

Depending upon your llvm version, modify the above commands.

Now, you can compile C++ programs without passing any custom flags.

clang++ hello.cpp
Salil
  • 9,534
  • 9
  • 42
  • 56
0

I tried 1) manually linking 2) brew install llvm, but they did not work.

Finally, this worked for me: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

By setting the following env vars:

export CC=clang
export CXX=clang++
export MACOSX_DEPLOYMENT_TARGET=10.9
elarcoiris
  • 1,914
  • 4
  • 28
  • 30
Y Liu
  • 1
0

In my case, i did a millions things but i reckon following steps helped fix ruby installation.

  1. xcode-select --install
  2. Set these flags
export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

  1. sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

  2. export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

  3. rbenv install 2.6.3 -v

Sid
  • 1
  • 1
0

For me the error was: xcrun[20873:1179298] Failed to open macho file at /Library/Developer/CommandLineTools/usr/bin/clang++ for reading: Too many levels of symbolic links

So I opened my terminal and went to the following folder (as mentioned by the error message): /Library/Developer/CommandLineTools/usr/bin/

Then I deleted the shortcut file named clang++

sudo rm clang++

Next, I made a copy of executable file named clang and renamed the copied file to clang++

sudo cp clang clang++

And finally it works.

yunhasnawa
  • 815
  • 1
  • 14
  • 30