Impossibile compilare un programma C su un Mac dopo l'aggiornamento a Catalina 10.15


64

C'è una domanda precedente Impossibile compilare il programma C su un Mac dopo l'aggiornamento a Mojave e le risposte a questo hanno coperto la maggior parte delle variazioni su ciò che non va.

Ora, a partire da lunedì 2019-10-07, puoi eseguire l'aggiornamento a macOS Catalina 10.15. Ancora una volta, durante l'aggiornamento, la /usr/includedirectory è stata spazzata via dall'aggiornamento, anche se XCode 11.0 è stato installato prima dell'aggiornamento (da Mojave 10.14.6) a Catalina. Di conseguenza, i compilatori creati per aspettarsi che esista una /usr/includedirectory non funzionano più.

Il passaggio principale consigliato per i problemi di Mojave - utilizzando il comando:

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

non funziona fuori dal gate perché la directory /Library/Developer/CommandLineTools/Packages/non esiste (quindi non c'è ancora un.pkg file da aprire).

C'è un buon modo (ufficiale) per creare e popolare la directory /usr/include?


Non è necessario /usr/includeutilizzare gli strumenti di sviluppo di Apple con l'attuale Xcode di Apple. Le intestazioni e simili sono in Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (Mantenere le intestazioni in diverse directory è necessario per supportare più piattaforme di destinazione, ed è bene non avere un /usr/includeper assicurarsi che nessuna compilazione utilizzi accidentalmente i file da essa quando si sceglie una versione diversa dal sistema host.) Cosa xcode-select -pmostra per il percorso di la directory degli sviluppatori attiva?
Eric Postpischil,

Ho creato GCC 9.2.0 (su Mojave) e prevede di poterlo utilizzare /usr/includeper le intestazioni di sistema. Mi piacerebbe poterlo usare ancora, anche se sospetto che Apple abbia finalmente gettato via le ultime vestigia di compatibilità con i sistemi Unix legacy (in una certa misura, la scrittura era sul muro con il sistema necessario per far funzionare Mojave '). Nel qual caso, probabilmente dovrò ricostruire GCC specificando in qualche modo la posizione corrente delle intestazioni del sistema - bashing manuale per come configurare GCC.
Jonathan Leffler,

1
@JonathanLeffler: Dopo l'aggiornamento a Catalina, devo anche affrontare il problema della mancanza di alcuni file (come stdlib.h) che vengono utilizzati dal pacchetto software R durante l'installazione di pacchetti R. Ho provato lo stesso di te per macOS_10.14, ma questo non è più possibile. GCC, c ++ o qualsiasi altra cosa sia installata in / Library / Developer / CommandLineTools / usr / bin, ma R non lo sa. Cosa posso fare?
sebastiann,

Da quando ho eseguito l'aggiornamento a Catalina una settimana o giù di lì, sono diventato vittima del famigerato problema di "doppia digitazione" sulle nuove tastiere Mac, sono passato a zsh, ho cambiato idea e ho deciso di tornare a bash e aggiornamento a bash5.0, ora sono qui perché non riesco a compilare bash5.0. Mi chiedo se la risposta corretta a questo problema non sia solo quella di tagliare le mie perdite e passare ad Arch?
DryLabRebel,

Un modo per aggirare il problema è usare i compilatori Xcode: se sono installati, sanno dove trovare le intestazioni del sistema. Anche la tecnica CPATH nella risposta accettata sembra funzionare correttamente. Non ho ancora sofferto su un Mac di "doppia digitazione" (di cui sono a conoscenza). Ho fatto decidere al mio iPhone di aver digitato ogni sorta di cose interessanti, ma finora, toccando il legno, il mio MacBook Pro è andato bene.
Jonathan Leffler,

Risposte:


30

Per me aggiungendo il seguente percorso per CPATHrisolvere il problema:

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

Ho provato ad aggiungere il CPATH; tuttavia, sto ancora ricevendo lo stesso errore. sto solo cercando di fare un semplice cout << "ciao";
Jon Pellant,

1
Quando ho provato questo, ha funzionato in un test casuale con un GCC 9.2.0 costruito sotto Mojave usando quello che ora è Xcode 11.1 - grazie.
Jonathan Leffler,

Questo ha funzionato per me con GCC 9.2.0_1
Sandeep,

5
Se stai usando gli strumenti da riga di comando invece di Xcode.app, usaexport CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
nalzok

Una stranezza : ho un po 'di codice che è iniziato#include <stdlib.h>e poi non è riuscito a compilare lamentandosi di: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);—— Eppure, quando lo aggiungo#include <ctype.h>prima#include <stdlib.h>, si compila OK. Continuo a capire cosa significhi e come gestirlo automaticamente.
Jonathan Leffler,

48

Prima di procedere, assicurarsi di installare gli strumenti da riga di comando xcode.

xcode-select --install

In realtà, puoi farlo! In realtà tutte le intestazioni C si trovano qui in questa cartella:

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

Dobbiamo solo creare un collegamento simbolico per tutti i file delle intestazioni in questa cartella:

/usr/local/include/

Ha funzionato per me! la seguente riga di comando si occuperà di tutti i problemi:

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

Riceverai qualche avviso. Alcune delle intestazioni esistono già, in questo modo:

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

totalmente ok da ignorare. È tutto.


1
Sì, suppongo che sia possibile - grazie per il suggerimento. In realtà non corrisponde ai miei requisiti di "igiene del sistema" (ad es. Quelle intestazioni duplicate) e la /usr/local/gerarchia di directory è pensata per il software locale piuttosto che per il software di sistema. IMO, le intestazioni dovrebbero essere presenti /usr/includee Apple è solo un dolore.
Jonathan Leffler,

1
C'è un modo per aggirare, può funzionare, puoi provare. In modalità di ripristino, disabilitare il SIP, quindi montare la /modalità di scrittura. Quindi popolare la /usr/includecartella. È perché in 10.15, il sistema si monta in modalità di sola lettura. senza disabilitare il SIP, non sarà possibile montare il volume di sistema.
Roy,

@KomolNathRoy: grazie per i tuoi suggerimenti. Questo ha funzionato molto bene per me. Potrei finalmente installare tutti i pacchetti desiderati nel software statistico R, perché nessun R trova tutto ciò di cui ha bisogno per l'installazione.
sebastiann,

7
Questa soluzione ha funzionato per me su Catalina 10.15
Matthew Barbara,

2
La disabilitazione del SIP non è accettabile per me, anche come misura temporanea.
Jonathan Leffler,

22

TL; DR

Sembra che Apple consideri /usr/includequalcosa che ha fatto la strada del dodo - è estinto - o forse è come il pappagallo di Monty Python .

L'uso del GCC fornito da Apple (in realtà, è Clang con qualsiasi altro nome, come mostrano le informazioni sulla versione) o Clang evita problemi. Entrambi /usr/bin/gcce /usr/bin/clangtroveranno le librerie di sistema quattro livelli di directory di seguito:

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

Se costruisci il tuo GCC o un altro compilatore, dovrai (probabilmente) configurarlo per trovare le librerie di sistema nella directory dell'applicazione Xcode.

esplorazioni

Immediatamente dopo l'aggiornamento, ho eseguito XCode 11.0. Voleva installare alcuni componenti extra, quindi l'ho lasciato fare. Tuttavia, ciò non è stato ripristinato /usr/includeo la directory in /Library.

Uno degli altri consigli nella domanda precedente era di eseguire:

xcode-select --install

Nel fare ciò, ha affermato di aver scaricato le utility della riga di comando e ha assicurato la presenza di /usr/bin/gcce /usr/bin/clangcosì via. È un passaggio utile (anche se non ho verificato definitivamente se erano presenti prima).

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

Utilizzando /usr/bin/gcc, è ora possibile compilare programmi:

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

Tuttavia, /usr/includemanca ancora. C'è una directory sotto /Libraryora:

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

Né la directory Systemné la Librarydirectory contengono qualcosa di molto promettente.

Quando tutto il resto fallisce, leggi il manuale

Passaggio successivo: trova e leggi le note di rilascio:

Non ci sono informazioni che si riferiscono a questo. Quindi, la probabilità è (AFAICS, dopo solo un'ora o due di sforzi) che Apple non supporta più /usr/include- anche se ha ancora un caricamento completo /usr/lib(no/lib però).

È ora di controllare un'altra compilation con l'opzione GCC -vaggiunta (nel makefile che ho usato, l'impostazione UFLAGSaggiunge l'opzione alla riga di comando del compilatore 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
$

Le informazioni chiave in quella bufera di dati sono:

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

Questa è effettivamente la directory 'root' per la compilazione, quindi ci dovrebbero essere sottodirectory sotto quella per usre 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
$

Ciò dimostra che il nome della directory lungo un miglio e totalmente non memorizzabile contiene le intestazioni C e POSIX standard, oltre a extra specifici di Apple.

La /usr/local/directory precedente sembra essere intatta; l'avvertenza di usr/local/includenon esistere sotto il -isysrootdirè innocuo (e non visibile senza l' -vopzione).


Spiacenti, impossibile seguire il tuo suggerimento. Ricevo lo stesso errore con l'aggiornamento catalina. Con vscode non sono riuscito a creare app C ++ e wchar.hnon ho trovato errori. Ho provato ad includere questa cartella -I / Applicazioni / Xcode.app / Sommario / Sviluppatore / Piattaforme / MacOSX.platform / Developer / SDKs / MacOSX.sdk / usr / include e iam ottenendo altri errori come sui simboli mancanti per "errore: nessun membro chiamato "isless" nello spazio dei nomi globale "
user3279954

Abilitato --verbosenel file delle attività e notato che vs code sta esaminando una /usr/include/c++/v1/cartella che non esiste più in Catalina. Aggiunta anche la seguente cartella insieme a sdk include sopra e ora funziona. "-I / Library / Developer / CommandLineTools / usr / include / c ++ / v1 /",
user3279954

@trojanfoe - Preferisco SCCS ma nel 1999 non era chiaro se SCCS avrebbe funzionato in modo sano dopo Y2K (e non esisteva una buona implementazione open source di SCCS di cui ero a conoscenza), quindi con riluttanza sono passato a RCS.
Jonathan Leffler,

Wow: D Quindi, qual è il problema con la /usr/includescomparsa? Faceva sempre implicitamente parte del percorso di inclusione del compilatore, quindi l'utente non aveva mai avuto bisogno di conoscerlo (a parte quando cercavi di trovare dove era stato dichiarato qualcosa). Clang fa lo stesso con il suo percorso SDK sotto, Xcode.appquindi l'effetto netto è lo stesso.
trojanfoe,

1
@trojanfoe: un problema (il mio problema principale) con /usr/includeAWOL andato è che se hai creato il tuo GCC dal sorgente, è stato probabilmente compilato per trovare le intestazioni di sistema /usr/includee quindi le compilazioni falliscono. Voglio usare l'ultimo GCC e Clang. Sono felice di usare il Clang di Apple, ma non sono contento di usare il Clang di Apple mascherato da GCC - non è lo stesso di GCC. Non ho ancora elaborato una ricetta per costruire GCC con le intestazioni di sistema trasferite. (Penso che --with-native-system-header-dir="${XCODE_HDR}"sia parte della risposta; non è, tuttavia, l'intera risposta.)
Jonathan Leffler,

7

Impostare le seguenti Makevariabili implicite in modo che puntino a dove si trovano ora le intestazioni per Xcode Command Line Tools (Xcode CLI):

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' -isysrootopzione aggiorna la posizione dei file root dalla directory principale del sistema /.

Quindi, questo assicura che i /usr/*file comuni vengano trovati nella loro nuova posizione.

Cioè, i file su /Library/Developer/CommandLineTools/SDKs/MacOSX.sdksono ora trovati. Questi file sono:

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

Nei miei makefile (e nella maggior parte degli altri makefile che vedo), CFLAGSè molto più complesso di una singola opzione: l' -isysrootopzione dovrebbe essere "in aggiunta" alle altre impostazioni (molte altre impostazioni). Potrebbe esserci un kernel di un'idea qui (passa l' -isysrootopzione e la posizione sotto /Library/Developer/…), ma avrebbe bisogno di un po 'di lucidatura prima che sia pronto per la prima serata.
Jonathan Leffler,

@JonathanLeffler L'utilizzo export CFLAGS+=-isysroot ...invece funzionerà per quel caso d'uso. Questa è l'unica soluzione che ha funzionato per me (su Mojave (10.14) con Catalina (10.15) SDK. Non ho il .pkgfile di cui tutti parlano, anche se il mio XCode e gli strumenti da riga di comando sono aggiornati).
Norswap,

@Norswap - c'è un'enorme differenza tra l'uso di CFLAGS=…e CFLAGS+=….
Jonathan Leffler,

@JonathanLeffler concordato. Ho aggiornato la risposta da utilizzare +=. Grazie @Norswap.
cappotto il

1
In alternativa, ho capito che l'impostazione SDKROOTcon lo stesso valore sdk ( /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) funzionerà anche per me!
Norswap,

4

Sono un principiante con il compilatore C ++ per R in OSX e ho avuto lo stesso problema che C ++ non riusciva a trovare l'intestazione dopo l'aggiornamento del sistema operativo ( manca math.h sebbene fosse lì ). Ho seguito le istruzioni da https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ ma non è cambiato nulla.

Alla fine, ha funzionato per me dopo aver reinstallato la CLI di Xcode

xcode-select --install

e quindi cambia i flag in Var come suggerito da @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

1

Nel mio caso mi sembrava di avere llvme gccanche installato utilizzando homebrew. Quando ho rimosso quelli, e quindi ho fatto pieno affidamento sul clang di macOS, è stato possibile trovare di nuovo le intestazioni e la compilazione funzionate.


0

La dipendenza apue.h mancava ancora nel mio /usr/local/includedopo aver seguito Komol Nath Roy risposta di in questa domanda.

Ho scaricato manualmente la dipendenza da git e l'ho inserita /usr/local/include


L'intestazione apue.hproviene da W Richard Stevens, Stephen A Rago Advanced Programming in Unix Environment, 3rd Edn 2013. AFAIK, non è mai stato fornito da Apple come header di sistema. (Non è /usr/includesulla mia macchina che esegue ancora Mojave.) Se è stato installato una volta /usr/include, è stato probabilmente creato manualmente anziché essere fornito da Apple. Come tale, avrebbe dovuto essere installato in /usr/local/includeprecedenza.
Jonathan Leffler,

Scusa la mia ingenua domanda, ma questa settimana ho appena messo le mani su C ++. Le dipendenze / intestazioni sono gestite manualmente in c ++? in caso affermativo, devo inserire tutte le dipendenze / intestazioni dette /usr/include?
Matthew Barbara,

1
Q1: più o meno. Dipende un po 'da cosa intendi, ma devi preoccuparti delle dipendenze e delle intestazioni per C o C ++ se le intestazioni non sono standard sulle macchine con cui stai lavorando. Poi arriva la domanda: qual è lo standard? E la migliore risposta che si può dare è "dipende", e dipende da molti fattori, tra cui "piattaforma" (O / S, compilatore). Q2 è "No, di solito non dovresti inserire nulla /usr/include" - usa /usr/local/includeinvece. In generale, è più sicuro di lasciare /usr/includee /usr/libsolo, e aggiungere sotto il materiale /usr/local, invece.
Jonathan Leffler,

0

La soluzione è stata più semplice di quanto pensassi. Installa clang / llvm.

brew install llvm

Quindi dobbiamo creare noi stessi i collegamenti simbolici.

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

E

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

A seconda della versione di llvm, modificare i comandi sopra.

Ora puoi compilare programmi C ++ senza passare alcun flag personalizzato.

clang++ hello.cpp


0

Per me funziona bene come segue:

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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.