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

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?

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

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.

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:

• Note di rilascio di Xcode 11
• Note di rilascio di macOS Catalina 10.15

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

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

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

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.

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

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

Ho provato 1) collegando manualmente 2) brew install llvm, ma non hanno funzionato.

Infine, ha funzionato per me: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

Impostando le seguenti variabili env:

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

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