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

64

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?

Jonathan Leffler
la source
Vous n'avez pas besoin /usr/included'utiliser les outils de développement d'Apple avec le Xcode actuel d'Apple. Les en-têtes et autres sont là Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (Garder les en- têtes dans des répertoires différents est nécessaire pour soutenir les plates - formes cibles multiples, et il est bon de ne pas avoir un /usr/includepour vous assurer qu'aucun compiles utiliser accidentellement des fichiers à partir quand le ciblage d' un autre version du système hôte). Qu'est-ce xcode-select -pspectacle pour le chemin d'accès le répertoire de développeur actif?
Eric Postpischil
J'ai construit GCC 9.2.0 (sur Mojave) et il s'attend à pouvoir l'utiliser /usr/includepour les en-têtes du système. J'aimerais pouvoir l'utiliser encore, même si je soupçonne qu'Apple a finalement jeté les derniers vestiges de compatibilité avec les systèmes Unix hérités (dans une certaine mesure, l'écriture était sur le mur avec le système requis pour faire fonctionner Mojave) '). Dans ce cas, je dois probablement reconstruire GCC en spécifiant l'emplacement actuel des en-têtes du système en quelque sorte - dénigrement manuel pour savoir comment configurer GCC.
Jonathan Leffler
1
@JonathanLeffler: Après la mise à jour vers catalina, je suis également confronté au problème de manque de certains fichiers (comme stdlib.h) qui sont utilisés par le progiciel R lors de l'installation des progiciels R. J'ai essayé le même que vous pour macOS_10.14, mais ce n'est plus possible. GCC, c ++ ou tout ce qui est installé dans / Library / Developer / CommandLineTools / usr / bin, mais R ne sait pas. Que puis-je faire?
sebastiann
Depuis que j'ai mis à niveau vers Catalina il y a environ une semaine, je suis devenu victime du problème désormais notoire de "double frappe" sur les nouveaux claviers Mac, je suis passé à zsh, j'ai changé d'avis et j'ai décidé de revenir à bash et passer à bash5.0, maintenant je suis ici parce que je ne peux pas compiler bash5.0. Je me demande si la bonne réponse à ce problème n'est pas simplement de réduire mes pertes et de passer à Arch?
DryLabRebel
Une façon de contourner le problème est d'utiliser les compilateurs Xcode - s'ils sont installés, ils savent où trouver les en-têtes du système. La technique CPATH dans la réponse acceptée semble également fonctionner correctement. Je n'ai pas encore souffert sur un Mac de "double frappe" (que je sache). J'ai eu mon iPhone décider d'avoir tapé toutes sortes de choses intéressantes, mais jusqu'à présent, touchez le bois, mon MacBook Pro est OK.
Jonathan Leffler

Réponses:

30

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
Hamid
la source
J'ai essayé d'ajouter le CPATH; cependant, je reçois toujours cette même erreur. juste essayer de faire un simple cout << "bonjour";
Jon Pellant
1
Lorsque j'ai essayé cela, cela a fonctionné dans un test occasionnel avec un GCC 9.2.0 construit sous Mojave en utilisant ce qui est maintenant Xcode 11.1 - merci.
Jonathan Leffler
Cela a fonctionné pour moi avec GCC 9.2.0_1
Sandeep
6
Si vous utilisez les outils de ligne de commande au lieu de Xcode.app, utilisezexport CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
nalzok
Une bizarrerie - j'ai du code qui a commencé#include <stdlib.h>et n'a pas réussi à compiler se plaindre de: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);—— Pourtant, quand j'ajoute#include <ctype.h>avant#include <stdlib.h>, il compile OK. Toujours en train de comprendre ce que cela signifie et comment le gérer automatiquement.
Jonathan Leffler
48

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.

Roy
la source
1
Oui, je suppose que c'est possible - merci pour la suggestion. Il ne correspond pas vraiment à mes exigences en matière d'hygiène du système (par exemple, ces en-têtes en double) et la /usr/local/hiérarchie des répertoires est destinée aux logiciels locaux plutôt qu'aux logiciels système. OMI, les en-têtes devraient être là /usr/includeet Apple est juste une douleur.
Jonathan Leffler
1
Il existe un moyen de contourner, peut fonctionner, vous pouvez essayer. En mode de récupération, désactivez le SIP, puis montez le /en mode d'écriture. Remplissez ensuite le /usr/includedossier. C'est parce que dans 10.15, le système se monte en mode lecture seule. sans désactiver le SIP, vous ne pourrez pas monter le volume système.
Roy
@KomolNathRoy: merci pour vos conseils. Cela a très bien fonctionné pour moi. J'ai enfin pu installer tous mes packages souhaités dans le logiciel statistique R, car aucun R ne trouve tout ce dont il a besoin pour l'installation.
sebastiann
7
Cette solution a fonctionné pour moi sur Catalina 10.15
Matthew Barbara
2
La désactivation du SIP n'est pas acceptable pour moi, même à titre temporaire.
Jonathan Leffler
22

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:

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).

Jonathan Leffler
la source
Désolé, je n'ai pas pu suivre votre suggestion. Je reçois la même erreur avec la mise à jour de catalina. Avec vscode, je ne pouvais pas créer d'applications C ++ et obtenir une wchar.herreur introuvable. J'ai essayé d'inclure ce dossier -I / Applications / Xcode.app / Contents / Developer / Platforms / MacOSX.platform / Developer / SDKs / MacOSX.sdk / usr / include et iam obtenant d'autres erreurs comme à propos des symboles manquants pour "erreur: aucun membre nommé "isless" dans l'espace de noms global "
user3279954
Activé --verbosedans le fichier de tâches et remarqué que vs code recherche un /usr/include/c++/v1/dossier qui n'existe plus maintenant en catalina. Ajout du dossier suivant ainsi que de l'inclusion sdk ci-dessus et maintenant cela fonctionne. "-I / Library / Developer / CommandLineTools / usr / include / c ++ / v1 /",
user3279954
@trojanfoe - Je préfère SCCS, mais en 1999, il n'était pas clair si SCCS allait fonctionner correctement après l'an 2000 (et il n'y avait pas une bonne implémentation open source de SCCS que je connaissais), j'ai donc à contrecœur basculé vers RCS.
Jonathan Leffler
Wow: D Alors, quel est le problème avec la /usr/includedisparition? Il faisait toujours implicitement partie du chemin d'inclusion du compilateur, de sorte que l'utilisateur n'avait jamais besoin de le savoir (sauf lorsque vous essayiez de trouver où quelque chose a été déclaré). Clang fait de même avec son chemin de SDK sous Xcode.appdonc l'effet net est le même.
trojanfoe
1
@trojanfoe: un problème (mon principal problème) avec /usr/includeAWOL disparu est que si vous avez construit votre propre GCC à partir de la source, il a probablement été compilé pour trouver les en-têtes du système /usr/includeet donc les compilations échouent. Je veux utiliser le dernier GCC ainsi que Clang. Je suis heureux d'utiliser Clang d'Apple, mais je ne suis pas heureux d'utiliser Clang d'Apple se faisant passer pour GCC - ce n'est pas la même chose que GCC. Je n'ai pas encore trouvé de recette pour construire GCC avec les en-têtes du système déplacés. (Je pense que cela --with-native-system-header-dir="${XCODE_HDR}"fait partie de la réponse, mais ce n'est pas toute la réponse.)
Jonathan Leffler
7

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
sans poil
la source
Dans mes makefiles (et la plupart des autres makefiles que je vois), CFLAGSest beaucoup plus complexe qu'une seule option - l' -isysrootoption devrait être «en plus» des autres paramètres (beaucoup d'autres paramètres). Il peut y avoir un noyau d'une idée ici (passez l' -isysrootoption et l'emplacement ci-dessous /Library/Developer/…), mais il faudrait un peu de polissage avant qu'il ne soit prêt pour les heures de grande écoute.
Jonathan Leffler
@JonathanLeffler Utiliser à la export CFLAGS+=-isysroot ...place fonctionnera pour ce cas d'utilisation. C'est la seule solution qui a fonctionné pour moi (sur Mojave (10.14) avec Catalina (10.15) SDK. Je n'ai pas le .pkgfichier dont tout le monde parle même si mes XCode et outils de ligne de commande sont à jour).
Norswap
@Norswap - il y a une énorme différence entre l'utilisation de CFLAGS=…et CFLAGS+=….
Jonathan Leffler
@JonathanLeffler a accepté. J'ai mis à jour la réponse à utiliser +=. Merci @Norswap.
manteau
1
Alternativement, j'ai compris que le réglage SDKROOTsur la même valeur sdk ( /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) fonctionnera également pour moi!
Norswap
4

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
Nancy
la source
1

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.

frbl
la source
0

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

Matthew Barbara
la source
L'en-tête apue.hprovient de W Richard Stevens, Stephen A Rago Advanced Programming in the Unix Environment, 3rd Edn 2013. AFAIK, il n'a jamais été fourni par Apple comme en-tête du système. (Ce n'est pas /usr/includesur ma machine qui exécute toujours Mojave.) S'il a été installé une fois /usr/include, il a probablement été créé manuellement plutôt que fourni par Apple. En tant que tel, il aurait dû être installé /usr/local/includeprécédemment.
Jonathan Leffler
Excusez ma question naïve mais je viens de mettre la main sur C ++ cette semaine. Les dépendances / en-têtes sont-ils gérés manuellement en c ++? si oui, dois-je y mettre toutes les dépendances / en-têtes /usr/include?
Matthew Barbara
1
Q1: Plus ou moins. Cela dépend un peu de ce que vous voulez dire, mais vous devez vous soucier des dépendances et des en-têtes pour C ou C ++ si les en-têtes ne sont pas standard sur la ou les machines avec lesquelles vous travaillez. Vient ensuite la question - quelle est la norme? Et la meilleure réponse qui puisse être donnée est "ça dépend", et cela dépend de beaucoup de facteurs - y compris la "plateforme" (O / S, compilateur). Q2 est "Non, vous ne devriez généralement rien mettre /usr/include" - utilisez /usr/local/includeplutôt. En général, il est plus sûr de laisser /usr/includeet /usr/libseul, et ajouter de la matière en /usr/localplace.
Jonathan Leffler
0

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
Salil
la source
0

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
pfcstyle
la source