Nach dem Upgrade auf Catalina 10.15 kann kein C-Programm auf einem Mac kompiliert werden
Lesezeit: 5 Minuten
Jonathan Leffler
Es gibt eine frühere Frage: C-Programm kann nach dem Upgrade auf Mojave nicht auf einem Mac kompiliert werden, und die Antworten darauf haben die meisten Variationen darüber abgedeckt, was schief geht.
Jetzt – ab Montag, 07.10.2019 – können Sie auf macOS Catalina 10.15 upgraden. Noch einmal, während des Upgrades, die /usr/include Verzeichnis wurde von dem Update umgehauen, obwohl XCode 11.0 vor dem Upgrade (von Mojave 10.14.6) auf Catalina installiert wurde. Folglich erwarten Compiler, dass es eine gibt /usr/include Verzeichnis funktionieren 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 aus dem tor da das verzeichnis /Library/Developer/CommandLineTools/Packages/ existiert nicht (also gibt es noch keine .pkg Datei zu öffnen).
Gibt es eine gute (offizielle) Möglichkeit, das Verzeichnis zu erstellen und zu füllen /usr/include?
Du brauchst nicht /usr/include um Apples Entwicklertools mit Apples aktuellem Xcode zu verwenden. Die Header und so sind drin Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (Das Aufbewahren von Headern in verschiedenen Verzeichnissen ist notwendig, um mehrere Zielplattformen zu unterstützen, und es ist gut, keine zu haben /usr/include um sicherzustellen, dass keine Kompilierungen versehentlich Dateien davon verwenden, wenn sie auf eine andere Version als das Hostsystem abzielen.) Was tut xcode-select -p show für den Pfad zum aktiven Entwicklerverzeichnis?
– Eric Postpischil
7. Oktober 2019 um 23:47 Uhr
Ich habe GCC 9.2.0 (auf Mojave) gebaut und es erwartet, es verwenden zu können /usr/include für die Systemkopfzeilen. Ich würde das gerne immer noch verwenden können, obwohl ich vermute, dass Apple endlich die letzten Reste der Kompatibilität mit älteren Unix-Systemen weggeworfen hat (bis zu einem gewissen Grad war das Schreiben an der Wand mit dem System, das erforderlich ist, damit Mojave funktioniert ‘). In diesem Fall muss ich wahrscheinlich GCC neu erstellen, indem ich die aktuelle Position der Systemheader irgendwie angebe – manuelles Bashing für die Konfiguration von GCC.
– Jonathan Leffler
7. Oktober 2019 um 23:59 Uhr
@JonathanLeffler: Nach dem Update auf Catalina habe ich auch das Problem, dass einige Dateien (wie stdlib.h) fehlen, die vom Softwarepaket R beim Installieren von R-Paketen verwendet werden. Ich habe dasselbe wie du für macOS_10.14 versucht, aber das ist nicht mehr möglich. GCC, c++ oder was auch immer in /Library/Developer/CommandLineTools/usr/bin installiert ist, aber R weiß es nicht. Was kann ich machen?
– Sebastian
12. Oktober 2019 um 11:43 Uhr
Eine Möglichkeit, das Problem zu umgehen, besteht darin, die Xcode-Compiler zu verwenden – wenn sie installiert sind, wissen sie, wo sie die Systemheader finden. Die CPATH-Technik in der akzeptierten Antwort scheint ebenfalls gut zu funktionieren. Ich habe auf einem Mac noch nicht unter “Doppeleingabe” gelitten (soweit ich weiß). Ich habe mein iPhone entscheiden lassen, dass ich alle möglichen interessanten Sachen getippt habe, aber bis jetzt, berühren Sie Holz, mein MacBook Pro war in Ordnung.
– Jonathan Leffler
30. Oktober 2019 um 4:38 Uhr
Die akzeptierte Antwort brachte bash5.0 zum Kompilieren, aber jetzt stoße ich auf Probleme mit make und make install, die sehr ähnlich zu sein scheinen fatal error: wchar.h: No such file or directory # include <wchar.h> compilation terminated. Ich denke, sie werden morgen ein Problem darstellen. Vielen Dank für all Ihre Bemühungen, es war interessant und lehrreich.
– DryLabRebel
30. Oktober 2019 um 4:49 Uhr
Roy
Bevor Sie fortfahren, stellen Sie sicher, dass Sie die xcode-Befehlszeilentools installieren.
xcode-select --install
Eigentlich kann man das! Eigentlich sind alle C-Header hier in diesem Ordner zu finden:
Ja, ich nehme an, das ist möglich – danke für den Vorschlag. Es entspricht nicht wirklich meinen Anforderungen an die “Systemhygiene” (z. B. diese doppelten Header) und die /usr/local/ Die Verzeichnishierarchie ist eher für lokale Software als für Systemsoftware gedacht. IMO, die Header sollten drin sein /usr/include und Apple ist nur ein Schmerz.
– Jonathan Leffler
12. Oktober 2019 um 5:36 Uhr
Es gibt einen Weg, der funktioniert, Sie können es versuchen. Deaktivieren Sie im Wiederherstellungsmodus das SIP und mounten Sie dann die / im Schreibmodus. Füllen Sie dann die /usr/include Mappe. Dies liegt daran, dass das System in 10.15 im schreibgeschützten Modus bereitgestellt wird. ohne das SIP zu deaktivieren, können Sie das Systemvolume nicht mounten.
– Roy
12. Oktober 2019 um 9:38 Uhr
Das Deaktivieren des SIP ist für mich nicht akzeptabel, auch nicht als vorübergehende Maßnahme.
– Jonathan Leffler
13. Oktober 2019 um 1:01 Uhr
Dies ist die einzige Methode, die funktioniert hat, nachdem ich ein halbes Dutzend Anleitungen ausprobiert hatte, +1
– trdavidson
24. Februar 2020 um 16:51 Uhr
Die Lösung von @Roy hat bei mir nicht funktioniert. Außerdem verursachte es Probleme mit Rcpp auf Catalina. Ich habe das Problem wie hier beschrieben behoben: https://stackoverflow.com/questions/64565863/rcpp-not-working-on-r-3-6-3-macos-catalina-10-15-7/64618049#64618049
– Bob
1. November 2020 um 20:43 Uhr
Hamidreza Omidvar
Für mich fügt sich folgender Pfad hinzu CPATH Problem gelöst:
Ich habe versucht, den CPATH hinzuzufügen; Ich erhalte jedoch immer noch denselben Fehler. Ich versuche nur, einen einfachen Cout zu machen << "Hallo";
– Jon Pelant
10. Oktober 2019 um 18:52 Uhr
Als ich dies ausprobierte, funktionierte es in einem gelegentlichen Test mit einem GCC 9.2.0, der unter Mojave mit dem, was jetzt Xcode 11.1 ist, erstellt wurde – danke.
– Jonathan Leffler
11. Oktober 2019 um 11:32 Uhr
Wenn Sie die Befehlszeilentools anstelle von Xcode.app verwenden, verwenden Sie export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
– nalzok
19. Oktober 2019 um 5:49 Uhr
Eine andere Variante dazu ist: #include <stdlib.h> — #include <stdio.h> — int main(void) { printf("Hello World!\n"); return EXIT_SUCCESS; }. Mit den Headern in der Sequenz <stdlib.h> dann <stdio.h>, der Code kann nicht kompiliert werden; mit den Headern in umgekehrter Reihenfolge wird der Code ohne Twittering kompiliert. Es ist etwas Seltsames dabei <stdlib.h>. (Compiler-Optionen: 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 ist ein selbstgebautes 9.2.0.
– Jonathan Leffler
30. Oktober 2019 um 6:11 Uhr
@Guddu Ich glaube, letzteres ist ein Alias für ersteres. Ich persönlich bevorzuge SDKs/MacOSX.sdk da es bei jedem System-Upgrade immer auf das neueste SDK verweisen sollte.
– nalzok
3. August 2021 um 4:42 Uhr
Jonathan Leffler
TL;DR
Es scheint, dass Apple erwägt /usr/include als etwas, das den Weg des Dodos gegangen ist – es ist ausgestorben – oder vielleicht ist es wie das von Monty Python Papagei.
Die Verwendung des von Apple bereitgestellten GCC (eigentlich ist das Clang unter einem anderen Namen, wie die Versionsinformationen zeigen) oder Clang vermeidet Probleme. Beide /usr/bin/gcc und /usr/bin/clang finden Sie die Systembibliotheken vier Verzeichnisebenen darunter:
Wenn Sie Ihren eigenen GCC oder 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 tun. Dies wurde jedoch nicht wiederhergestellt /usr/include oder das Verzeichnis unter /Library.
Einer der anderen Ratschläge in der vorherigen Frage war, Folgendes auszuführen:
xcode-select --install
Dabei behauptete es, dass es die Befehlszeilenprogramme heruntergeladen habe, und stellte dies sicher /usr/bin/gcc und /usr/bin/clang usw waren dabei. 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
$
Verwenden /usr/bin/gccist es nun möglich, Programme zu kompilieren:
$ 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
$
Jedoch, /usr/include fehlt noch. Darunter befindet sich ein Verzeichnis /Library jetzt:
$ 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 die System noch die Library Verzeichnis enthalten alles sehr vielversprechend.
Wenn alles andere fehlschlägt, lesen Sie das Handbuch
Nächster Schritt – Suchen und lesen Sie die Versionshinweise:
Da sind keine Informationen drin, die sich darauf beziehen. Es besteht also die Wahrscheinlichkeit (AFAICS, nach nur ein oder zwei Stunden Aufwand), dass Apple keinen Support mehr hat /usr/include – obwohl es immer noch eine voll geladene hat /usr/lib (nein /lib obwohl).
Zeit, eine andere Zusammenstellung mit GCC-Option zu überprüfen -v hinzugefügt (in dem von mir verwendeten Makefile, setting UFLAGS fügt die Option zur C-Compiler-Befehlszeile hinzu):
Dies zeigt, dass der kilometerlange und völlig unmerkliche Verzeichnisname die standardmäßigen C- und POSIX-Header sowie Apple-spezifische Extras enthält.
Der Vorherige /usr/local/ Verzeichnis scheint intakt zu sein; die Warnung vor usr/local/include nicht vorhanden unter der -isysrootdir ist harmlos (und nicht sichtbar ohne die -v Möglichkeit).
Entschuldigung, ich konnte Ihrem Vorschlag nicht folgen. Ich bekomme den gleichen Fehler mit dem Catalina-Update. Mit vscode konnte ich keine C++ Apps bauen und bekomme wchar.h kein Fehler gefunden. Ich habe versucht, diesen Ordner -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include einzuschließen, und ich erhalte andere Fehler wie etwa fehlende Symbole für “error: no member mit dem Namen ‘isless’ im globalen Namensraum”
– Benutzer3279954
10. Oktober 2019 um 7:00 Uhr
@trojanfoe – Ich bevorzuge SCCS, aber 1999 war nicht klar, ob SCCS nach Y2K vernünftig funktionieren würde (und es gab keine gute Open-Source-Implementierung von SCCS, von der ich wusste), also wechselte ich widerwillig zu RCS.
– Jonathan Leffler
10. Oktober 2019 um 13:05 Uhr
Wenn jemand immer noch darauf stößt, nachdem er die Schritte hier befolgt hat, überprüfen Sie, ob dies der Fall ist llvm installiert über selbstgebraut und versuchen Sie es vollständig zu deinstallieren. Das hat es für mich gelöst.
– Nitza
11. Oktober 2019 um 2:27 Uhr
@trojanfoe: ein Problem (mein Hauptproblem) mit /usr/include AWOL gegangen ist, dass, wenn Sie Ihren eigenen GCC aus dem Quellcode erstellt haben, dieser wahrscheinlich kompiliert wurde, um die Systemheader darin zu finden /usr/include und deshalb scheitern die Kompilierungen. Ich möchte sowohl den neuesten GCC als auch Clang verwenden. Ich verwende gerne Apples Clang, aber ich bin nicht glücklich darüber, Apples Clang zu verwenden, das sich als GCC tarnt – es ist nicht dasselbe wie GCC. Ich habe noch kein Rezept zum Erstellen von GCC mit verschobenen Systemheadern ausgearbeitet. (Ich finde --with-native-system-header-dir="${XCODE_HDR}" ist Teil der Antwort; es ist jedoch nicht die ganze Antwort.)
– Jonathan Leffler
11. Oktober 2019 um 9:54 Uhr
@Nitza Ich bin mit deinem Kommentar auf Gold gestoßen! ich hatte llvm von Homebrew installiert, weil ich hatte ccls Eingerichtet. Ich benutze jetzt tatsächlich clangdalso verschwanden diese Clang-Build-Probleme danach brew uninstall llvm. Vielen Dank.
– Steven Lu
28. November 2020 um 21:29 Uhr
ohne Mantel
Stellen Sie implizit Folgendes ein Make Variablen, die darauf verweisen, wo sich die Header jetzt für Xcode Command Line Tools (Xcode CLI) befinden:
Das -isysroot Möglichkeit aktualisiert den Speicherort der Root-Dateien weg vom System-Root-Verzeichnis /.
Dies stellt also sicher, dass die gemeinsame /usr/* Dateien werden an ihrem neuen Ort gefunden.
Das heißt, die Dateien unter /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk sind jetzt gefunden. Diese Dateien sind:
Entitlements.plist
Library
SDKSettings.json
SDKSettings.plist
System
usr
Nancy
Ich bin ein Neuling mit dem C++-Compiler für R in OSX und habe das gleiche Problem, dass C++ den Header nicht finden konnte, nachdem das Betriebssystem aktualisiert wurde (math.h fehlt, obwohl es da war). Ich habe die Anweisungen von befolgt https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ aber es hat sich nichts 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 @Coatless vorgeschlagen hat:
Unter MacOS Catalina 10.15.4 musste ich mit Xcode Version 11.5 (11E608c) auch den Bibliothekspfad in meiner .zshrc aktualisieren (die MacOSX.sdk-Pfade sind neu):
Du brauchst nicht
/usr/includeum Apples Entwicklertools mit Apples aktuellem Xcode zu verwenden. Die Header und so sind drinXcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (Das Aufbewahren von Headern in verschiedenen Verzeichnissen ist notwendig, um mehrere Zielplattformen zu unterstützen, und es ist gut, keine zu haben/usr/includeum sicherzustellen, dass keine Kompilierungen versehentlich Dateien davon verwenden, wenn sie auf eine andere Version als das Hostsystem abzielen.) Was tutxcode-select -pshow für den Pfad zum aktiven Entwicklerverzeichnis?– Eric Postpischil
7. Oktober 2019 um 23:47 Uhr
Ich habe GCC 9.2.0 (auf Mojave) gebaut und es erwartet, es verwenden zu können
/usr/includefür die Systemkopfzeilen. Ich würde das gerne immer noch verwenden können, obwohl ich vermute, dass Apple endlich die letzten Reste der Kompatibilität mit älteren Unix-Systemen weggeworfen hat (bis zu einem gewissen Grad war das Schreiben an der Wand mit dem System, das erforderlich ist, damit Mojave funktioniert ‘). In diesem Fall muss ich wahrscheinlich GCC neu erstellen, indem ich die aktuelle Position der Systemheader irgendwie angebe – manuelles Bashing für die Konfiguration von GCC.– Jonathan Leffler
7. Oktober 2019 um 23:59 Uhr
@JonathanLeffler: Nach dem Update auf Catalina habe ich auch das Problem, dass einige Dateien (wie stdlib.h) fehlen, die vom Softwarepaket R beim Installieren von R-Paketen verwendet werden. Ich habe dasselbe wie du für macOS_10.14 versucht, aber das ist nicht mehr möglich. GCC, c++ oder was auch immer in /Library/Developer/CommandLineTools/usr/bin installiert ist, aber R weiß es nicht. Was kann ich machen?
– Sebastian
12. Oktober 2019 um 11:43 Uhr
Eine Möglichkeit, das Problem zu umgehen, besteht darin, die Xcode-Compiler zu verwenden – wenn sie installiert sind, wissen sie, wo sie die Systemheader finden. Die CPATH-Technik in der akzeptierten Antwort scheint ebenfalls gut zu funktionieren. Ich habe auf einem Mac noch nicht unter “Doppeleingabe” gelitten (soweit ich weiß). Ich habe mein iPhone entscheiden lassen, dass ich alle möglichen interessanten Sachen getippt habe, aber bis jetzt, berühren Sie Holz, mein MacBook Pro war in Ordnung.
– Jonathan Leffler
30. Oktober 2019 um 4:38 Uhr
Die akzeptierte Antwort brachte bash5.0 zum Kompilieren, aber jetzt stoße ich auf Probleme mit make und make install, die sehr ähnlich zu sein scheinen
fatal error: wchar.h: No such file or directory # include <wchar.h> compilation terminated. Ich denke, sie werden morgen ein Problem darstellen. Vielen Dank für all Ihre Bemühungen, es war interessant und lehrreich.– DryLabRebel
30. Oktober 2019 um 4:49 Uhr