No se puede compilar un programa C en una Mac después de actualizar a Catalina 10.15

Hay una pregunta anterior No se puede compilar el programa C en una Mac después de actualizar a Mojave , y las respuestas a eso han cubierto la mayoría de las variaciones de lo que sale mal.

Ahora, a partir del lunes 2019-10-07, puede actualizar a macOS Catalina 10.15. Una vez más, durante la actualización, el /usr/includedirectorio quedó impresionado por la actualización, a pesar de que XCode 11.0 se instaló antes de actualizar (desde Mojave 10.14.6) a Catalina. En consecuencia, los compiladores creados para esperar que haya un /usr/includedirectorio ya no funcionan.

El principal paso recomendado para los problemas de Mojave: usar el comando:

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

no funciona fuera de la puerta porque el directorio /Library/Developer/CommandLineTools/Packages/no existe (por lo que todavía no hay un .pkgarchivo para abrir).

¿Hay una buena forma (oficial) de crear y completar el directorio /usr/include?

Para mí, agregar la siguiente ruta para CPATHresolver el problema:

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

Antes de continuar, asegúrese de instalar las herramientas de línea de comandos de xcode.

xcode-select --install

En realidad, puedes hacerlo! En realidad, todos los encabezados C se encuentran aquí en esta carpeta:

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

Solo necesitamos crear un enlace simbólico para todos los archivos de encabezados en esta carpeta:

/usr/local/include/

¡Funcionó para mí! La siguiente línea de comando se ocupará de todos los problemas:

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

Recibirás alguna advertencia. Algunos de los encabezados ya existen, como este:

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 bien ignorarlo. eso es todo.

TL; DR

Parece que Apple lo considera /usr/includecomo algo que ha seguido el camino del dodo, está extinto, o tal vez es como el Parrot de Monty Python .

Usar el GCC proporcionado por Apple (en realidad, es Clang con cualquier otro nombre, como lo muestra la información de la versión) o Clang evita problemas. Ambos /usr/bin/gccy /usr/bin/clangencontrarán las bibliotecas del sistema en cuatro niveles de directorio a continuación:

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

Si crea su propio GCC u otro compilador, (probablemente) necesitará configurarlo para encontrar las bibliotecas del sistema en el directorio de la aplicación Xcode.

Exploraciones

Inmediatamente después de la actualización, ejecuté XCode 11.0. Quería instalar algunos componentes adicionales, así que lo dejé hacerlo. Sin embargo, eso no se restableció /usr/includeo el directorio bajo /Library.

Uno de los otros consejos en la pregunta anterior fue ejecutar:

xcode-select --install

Al hacerlo, alegó que descargó las utilidades de línea de comandos, y se aseguró de que /usr/bin/gccy /usr/bin/clangetc. estaban presentes. Ese es un paso útil (aunque definitivamente no verifiqué si estaban presentes antes).

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

Utilizando /usr/bin/gcc, ahora es posible compilar programas:

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

Sin embargo, /usr/includetodavía falta. Hay un directorio debajo /Libraryahora:

$ 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 el Systemni el Librarydirectorio contienen nada muy prometedor.

Cuando todo lo demás falla, lea el manual

Siguiente paso: busca y lee las notas de la versión:

• Notas de la versión de Xcode 11
• Notas de la versión de macOS Catalina 10.15

No hay información allí que se relacione con esto. Entonces, la probabilidad es (AFAICS, después de solo una o dos horas de esfuerzo) de que Apple ya no sea compatible /usr/include, aunque todavía tiene una carga completa /usr/lib( /libaunque no ).

Tiempo para verificar otra compilación con la opción GCC -vagregada (en el archivo MAKE que utilicé, la configuración UFLAGSagrega la opción a la línea de comando del compilador 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
$

La información clave en esa tormenta de datos es:

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

Ese es efectivamente el directorio 'raíz' para la compilación, por lo que debe haber subdirectorios debajo de eso para usry 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
$

Esto muestra que el nombre de directorio de una milla de largo y totalmente memorable contiene los encabezados estándar C y POSIX, además de los extras específicos de Apple.

El /usr/local/directorio anterior parece estar intacto; la advertencia sobre usr/local/includeno existir bajo el -isysrootdires inofensiva (y no visible sin la -vopción).

Establezca las siguientes Makevariables implícitas para señalar dónde se encuentran ahora los encabezados para las herramientas de línea de comandos de Xcode (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

La -isysrootopción actualiza la ubicación de los archivos raíz lejos del directorio raíz del sistema /.

Por lo tanto, esto garantiza que los /usr/*archivos comunes se encuentren en su nuevo lugar.

Es decir, /Library/Developer/CommandLineTools/SDKs/MacOSX.sdkahora se encuentran los archivos en . Estos archivos son:

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

Soy un novato con el compilador de C ++ para R en OSX y tuve el mismo problema que C ++ no pudo encontrar el encabezado después de que se actualizó el sistema operativo ( faltan math.h aunque estaba allí ). Seguí las instrucciones de https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ pero nada cambió.

Finalmente, funcionó para mí después de reinstalar la CLI de Xcode

xcode-select --install

y luego cambie las banderas a Var como @Coatless sugirió:

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

En mi caso, parecía tener llvm y gcctambién lo instalé usando homebrew. Cuando los eliminé y, por lo tanto, me basé completamente en el clang de macOS, pude encontrar los encabezados y la compilación funcionó nuevamente.

la dependencia de apue.h todavía faltaba en mi /usr/local/includedespués de seguir respuesta de Komol Nath Roy en esta pregunta.

Descargué la dependencia manualmente desde git y la coloqué en /usr/local/include

La solución fue más simple de lo que pensaba. Instala clang / llvm.

brew install llvm

Entonces necesitamos crear enlaces simbólicos nosotros mismos.

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

Y

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

Dependiendo de su versión llvm, modifique los comandos anteriores.

Ahora, puede compilar programas C ++ sin pasar ningún indicador personalizado.

clang++ hello.cpp

Intenté 1) vincular manualmente 2) brew install llvm, pero no funcionaron.

Finalmente, esto funcionó para mí: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503

Al configurar los siguientes entornos:

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

Para mí, funciona bien de la siguiente manera:

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