Impossible de compiler un programme C sur un Mac après la mise à niveau vers Catalina 10.15

Il y a une question précédente Impossible de compiler le programme C sur un Mac après la mise à niveau vers Mojave , et les réponses à cela ont couvert la plupart des variations sur ce qui ne va pas.

Maintenant - à partir du lundi 2019-10-07 - vous pouvez mettre à niveau vers macOS Catalina 10.15. Encore une fois, lors de la mise à niveau, le /usr/includerépertoire a été effacé par la mise à jour, même si XCode 11.0 a été installé avant la mise à niveau (de Mojave 10.14.6) vers Catalina. Par conséquent, les compilateurs conçus pour s'attendre à ce qu'il existe un /usr/includerépertoire ne fonctionnent plus.

La principale étape recommandée pour les problèmes de Mojave - en utilisant la commande:

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

ne fonctionne pas hors de la porte car le répertoire /Library/Developer/CommandLineTools/Packages/n'existe pas (il n'y a donc pas encore de .pkgfichier à ouvrir).

Existe-t-il un bon moyen (officiel) de créer et de remplir le répertoire /usr/include?

Pour moi, ajouter le chemin suivant pour CPATHrésoudre le problème:

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

Avant de continuer, assurez-vous d'installer les outils de ligne de commande xcode.

xcode-select --install

En fait, vous pouvez le faire! En fait, tous les en-têtes C se trouvent ici dans ce dossier:

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

Nous avons juste besoin de créer un lien symbolique pour tous les fichiers d'en-têtes dans ce dossier:

/usr/local/include/

Ça a marché pour moi! la ligne de commande suivante s'occupera de tous les problèmes:

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

Vous recevrez un avertissement. Certains en-têtes existent déjà, comme ceci:

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

totalement ok d'ignorer. c'est tout.

TL; DR

Il semble qu'Apple considère /usr/includecomme quelque chose qui a suivi le chemin du dodo - il est éteint - ou peut-être que c'est comme le perroquet de Monty Python .

L'utilisation du GCC fourni par Apple (en fait, c'est Clang sous un autre nom, comme le montrent les informations de version) ou Clang évite les problèmes. Les deux /usr/bin/gccet /usr/bin/clangtrouveront les bibliothèques système quatre niveaux de répertoire ci-dessous:

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

Si vous construisez votre propre GCC ou autre compilateur, vous devrez (probablement) le configurer pour trouver les bibliothèques système sous le répertoire d'application Xcode.

Explorations

Immédiatement après la mise à niveau, j'ai exécuté XCode 11.0. Il voulait installer des composants supplémentaires, alors je l'ai laissé faire. Cependant, cela n'a pas rétabli /usr/includeou le répertoire sous /Library.

L'un des autres conseils de la question précédente était de lancer:

xcode-select --install

Ce faisant, il a affirmé avoir téléchargé les utilitaires de ligne de commande, et il s'est assuré que /usr/bin/gccet /usr/bin/clangetc étaient présents. C'est une étape utile (même si je n'ai pas vérifié définitivement s'ils étaient présents auparavant).

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

A l'aide /usr/bin/gcc, il est désormais possible de compiler des programmes:

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

Cependant, /usr/includeil manque toujours. Il y a un répertoire sous /Librarymaintenant:

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

Ni le répertoire Systemni le Libraryrépertoire ne contiennent quelque chose de très prometteur.

Lorsque tout le reste échoue, lisez le manuel

Étape suivante - recherchez et lisez les notes de version:

• Notes de mise à jour de Xcode 11
• Notes de mise à jour de macOS Catalina 10.15

Il n'y a aucune information à ce sujet. Ainsi, la probabilité est (AFAICS, après seulement une heure ou deux d'efforts) qu'Apple ne prenne plus en charge /usr/include- bien qu'il ait toujours un système entièrement chargé /usr/lib(non /libcependant).

Il est temps de vérifier une autre compilation avec l'option GCC -vajoutée (dans le makefile que j'ai utilisé, le paramètre UFLAGSajoute l'option à la ligne de commande du compilateur C):

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

Les informations clés de ce blizzard de données sont les suivantes:

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

Il s'agit en fait du répertoire «racine» de la compilation, il devrait donc y avoir des sous-répertoires pour usret 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
$

Cela montre que le nom de répertoire long et totalement inoubliable contient les en-têtes C et POSIX standard, ainsi que des extras spécifiques à Apple.

Le /usr/local/répertoire précédent semble être intact; l'avertissement de usr/local/includene pas exister sous le -isysrootdirest inoffensif (et n'est pas visible sans l' -voption).

Définissez les Makevariables implicites suivantes pour indiquer où se trouvent désormais les en-têtes pour les outils de ligne de commande Xcode (CLI Xcode):

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

L' -isysrootoption met à jour l'emplacement des fichiers racine loin du répertoire racine du système /.

Ainsi, cela garantit que les /usr/*fichiers communs se trouvent à leur nouvel emplacement.

Autrement dit, les fichiers à /Library/Developer/CommandLineTools/SDKs/MacOSX.sdksont maintenant trouvés. Ces fichiers sont:

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

Je suis un débutant avec le compilateur C ++ pour R dans OSX et j'ai eu le même problème que C ++ n'a pas pu trouver l'en-tête après la mise à jour du système d'exploitation ( math.h manquant bien qu'il soit là ). J'ai suivi les instructions de https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ mais rien n'a changé.

Enfin, cela a fonctionné pour moi après avoir réinstallé la CLI Xcode

xcode-select --install

puis changez les drapeaux en Var comme l'a suggéré @Coatless:

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

Dans mon cas, j'ai semblé l'avoir installé llvmet gccaussi en utilisant homebrew. Lorsque j'ai supprimé ceux-ci, et que je me suis donc pleinement appuyé sur le macOS mac, il a pu trouver les en-têtes et la compilation fonctionnait à nouveau.

La dépendance apue.h manquait toujours dans mon /usr/local/includeaprès avoir suivi la réponse de Komol Nath Roy dans cette question.

J'ai téléchargé la dépendance manuellement depuis git et l'ai placée dans /usr/local/include

La solution était plus simple que je ne le pensais. Installez clang / llvm.

brew install llvm

Ensuite, nous devons créer nous-mêmes des liens symboliques.

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

Et

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

Selon votre version llvm, modifiez les commandes ci-dessus.

Maintenant, vous pouvez compiler des programmes C ++ sans passer aucun indicateur personnalisé.

clang++ hello.cpp

J'ai essayé 1) de lier manuellement 2) brew install llvm, mais ils n'ont pas fonctionné.

Enfin, cela a fonctionné pour moi: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

En définissant les vars env suivants:

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

Pour moi, cela fonctionne bien comme suit:

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