Can't compile a C program on a Mac after upgrading to Catalina 10.15
Before you proceed, make sure to install xcode command line tools.
xcode-select --installActually, 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 existsln: /usr/local/include//tclDecls.h: File existsln: /usr/local/include//tclPlatDecls.h: File existsln: /usr/local/include//tclTomMath.h: File existsln: /usr/local/include//tclTomMathDecls.h: File existsln: /usr/local/include//tk.h: File existsln: /usr/local/include//tkDecls.h: File existsln: /usr/local/include//tkPlatDecls.h: File existstotally ok to ignore. that's all.
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
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 --versionConfigured 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.1Apple clang version 11.0.0 (clang-1100.0.33.8)Target: x86_64-apple-darwin19.0.0Thread model: posixInstalledDir: /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 alco RCS/al.c,v al.cRCS/al.c,v --> al.crevision 1.7done/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/DeveloperCommandLineTools PrivateFrameworks$ ls /Library/Developer/CommandLineToolsLibrary SDKs usr$ ls /Library/Developer/CommandLineTools/SDKsMacOSX.sdk MacOSX10.14.sdk MacOSX10.15.sdk$ ls /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/Entitlements.plist SDKSettings.json SystemLibrary 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 wwco RCS/ww.c,v ww.cRCS/ww.c,v --> ww.crevision 4.9done/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 -ljlApple clang version 11.0.0 (clang-1100.0.33.8)Target: x86_64-apple-darwin19.0.0Thread model: posixInstalledDir: /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.cclang -cc1 version 11.0.0 (clang-1100.0.33.8) default target x86_64-apple-darwin19.0.0ignoring 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.sdkThat'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.sdkEntitlements.plist SDKSettings.json SystemLibrary SDKSettings.plist usr$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usrbin include lib libexec share$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/includeAppleTextureEncoder.h dns_util.h memory.h simdAssertMacros.h dtrace.h menu.h slapi-plugin.hAvailability.h editline miscfs spawn.hAvailabilityInternal.h err.h module.modulemap sqlite3.hAvailabilityMacros.h errno.h monetary.h sqlite3ext.hAvailabilityVersions.h eti.h monitor.h stab.h…lots more lines…dirent.h mach-o security xcselect.hdisktab.h mach_debug semaphore.h xlocaledispatch machine servers xlocale.hdlfcn.h malloc setjmp.h xpcdns.h math.h sgtty.h zconf.hdns_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).