Nach dem Upgrade auf Catalina 10.15 kann kein C-Programm auf einem Mac kompiliert werden

Es gibt eine frühere Frage: Nach dem Upgrade auf Mojave kann kein C-Programm auf einem Mac kompiliert werden. Die Antworten darauf haben die meisten Variationen der Fehler abgedeckt.

Ab Montag, dem 07.10.2019, können Sie jetzt ein Upgrade auf macOS Catalina 10.15 durchführen. Während des Upgrades wurde das /usr/includeVerzeichnis erneut durch das Update weggeblasen, obwohl XCode 11.0 vor dem Upgrade (von Mojave 10.14.6) auf Catalina installiert wurde. Folglich /usr/includefunktionieren Compiler, die so erstellt wurden, dass sie ein Verzeichnis erwarten, nicht mehr.

Der wichtigste empfohlene Schritt für die Mojave-Probleme - mit dem Befehl:

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

funktioniert nicht sofort, da das Verzeichnis /Library/Developer/CommandLineTools/Packages/nicht vorhanden ist (es muss also noch keine .pkgDatei geöffnet werden).

Gibt es eine gute (offizielle) Möglichkeit, das Verzeichnis zu erstellen und zu füllen /usr/include?

Für mich das Hinzufügen des folgenden Pfades, um CPATHdas Problem zu lösen:

export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

Bevor Sie fortfahren, stellen Sie sicher, dass Sie die xcode-Befehlszeilentools installieren.

xcode-select --install

Eigentlich kannst du es schaffen! Tatsächlich befinden sich alle C-Header hier in diesem Ordner:

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

Wir müssen nur einen Symlink für alle Header-Dateien in diesem Ordner erstellen:

/usr/local/include/

Es hat bei mir funktioniert! Die folgende Befehlszeile behebt alle Probleme:

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

Sie werden eine Warnung erhalten. Einige der Header sind bereits vorhanden:

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

völlig in Ordnung zu ignorieren. das ist alles.

TL; DR

Es scheint, dass Apple /usr/includeetwas betrachtet, das den Weg des Dodos gegangen ist - es ist ausgestorben - oder vielleicht ist es wie Monty Pythons Papagei .

Durch die Verwendung des von Apple bereitgestellten GCC (das ist Clang unter einem anderen Namen, wie die Versionsinformationen zeigen) oder Clang werden Probleme vermieden. Beide /usr/bin/gccund /usr/bin/clangfinden die Systembibliotheken vier Verzeichnisebenen unten:

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

Wenn Sie Ihren eigenen GCC oder einen anderen Compiler erstellen, müssen Sie ihn (wahrscheinlich) konfigurieren, um die Systembibliotheken im Xcode-Anwendungsverzeichnis zu finden.

Erkundungen

Unmittelbar nach dem Upgrade habe ich XCode 11.0 ausgeführt. Es wollte einige zusätzliche Komponenten installieren, also ließ ich es dies tun. Dies wurde jedoch nicht wiederhergestellt /usr/includeoder das Verzeichnis unter /Library.

Einer der anderen Ratschläge in der vorherigen Frage war:

xcode-select --install

Dabei wurde behauptet, dass die Befehlszeilen-Dienstprogramme heruntergeladen und sichergestellt wurden, dass /usr/bin/gccund /usr/bin/clangusw. vorhanden waren. Das ist ein nützlicher Schritt (obwohl ich nicht definitiv überprüft habe, ob sie vorher vorhanden waren).

$ /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
$

Mit /usr/bin/gcckönnen jetzt Programme programmiert werden:

$ 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
$

Fehlt /usr/includejedoch noch. Es gibt ein Verzeichnis unter /Library:

$ 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
$

Weder das Systemnoch das LibraryVerzeichnis enthalten etwas sehr Vielversprechendes.

Wenn alles andere fehlschlägt, lesen Sie das Handbuch

Nächster Schritt - Suchen und lesen Sie die Versionshinweise:

• Versionshinweise zu Xcode 11
• Versionshinweise zu macOS Catalina 10.15

Es gibt dort keine Informationen, die sich darauf beziehen. Die Wahrscheinlichkeit ist also (AFAICS, nach nur ein oder zwei Stunden), dass Apple nicht mehr unterstützt /usr/include- obwohl es immer noch voll geladen ist /usr/lib(nein, /libobwohl).

Zeit, eine weitere Kompilierung mit -vhinzugefügter GCC-Option zu überprüfen (in dem von mir verwendeten Makefile UFLAGSfügt die Einstellung die Option zur C-Compiler-Befehlszeile hinzu):

$ 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
$

Die wichtigsten Informationen in diesem Datenblizzard sind:

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

Das ist effektiv das 'root'-Verzeichnis für die Kompilierung, daher sollte es Unterverzeichnisse für usrund geben 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
$

Dies zeigt, dass der kilometerlange und völlig unvergessene Verzeichnisname die Standard-C- und POSIX-Header sowie Apple-spezifische Extras enthält.

Das vorherige /usr/local/Verzeichnis scheint intakt zu sein. Die Warnung, dass usr/local/includeunter dem nicht vorhanden -isysrootdirist, ist harmlos (und ohne die -vOption nicht sichtbar ).

MakeStellen Sie die folgenden impliziten Variablen so ein, dass sie darauf verweisen, wo sich die Header jetzt für Xcode Command Line Tools (Xcode CLI) befinden:

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

Die -isysrootOption aktualisiert den Speicherort der Stammdateien außerhalb des Systemstammverzeichnisses /.

Dies stellt also sicher, dass die allgemeinen /usr/*Dateien an ihrem neuen Ort gefunden werden.

Das heißt, die Dateien bei /Library/Developer/CommandLineTools/SDKs/MacOSX.sdkwerden jetzt gefunden. Diese Dateien sind:

Entitlements.plist 
Library
SDKSettings.json
SDKSettings.plist
System
usr

Ich bin ein Neuling mit C ++ - Compiler für R in OSX und habe das gleiche Problem, dass C ++ den Header nach der Aktualisierung des Betriebssystems nicht finden konnte ( fehlende math.h, obwohl es dort war ). Ich habe die Anweisungen von https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ befolgt, aber nichts hat sich geändert.

Schließlich funktionierte es für mich, nachdem ich die Xcode-CLI neu installiert hatte

xcode-select --install

und ändern Sie dann die Flags in Var, wie von @Coatless vorgeschlagen:

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

In meinem Fall schien ich Homebrew zu haben llvmund gccauch zu installieren. Als ich diese entfernte und mich somit voll und ganz auf das MacOS-Klirren stützte, konnte es die Header finden und das Kompilieren funktionierte wieder.

apue.h Abhängigkeit fehlte immer noch in meiner, /usr/local/includenachdem ich Komol Nath Roy Antwort in dieser Frage gefolgt war .

Ich habe die Abhängigkeit manuell von git heruntergeladen und in platziert /usr/local/include

Die Lösung war einfacher als ich dachte. Installieren Sie clang / llvm.

brew install llvm

Dann müssen wir selbst Symlinks erstellen.

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

Und

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

Ändern Sie abhängig von Ihrer llvm-Version die obigen Befehle.

Jetzt können Sie C ++ - Programme kompilieren, ohne benutzerdefinierte Flags zu übergeben.

clang++ hello.cpp

Ich habe versucht 1) manuell zu verknüpfen 2) brauen install llvm, aber sie haben nicht funktioniert.

Schließlich funktionierte dies für mich: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

Durch Einstellen der folgenden Umgebungsvariablen:

export CC=clang
export CXX=clang++
export MACOSX_DEPLOYMENT_TARGET=10.9

Für mich funktioniert es gut wie folgt:

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