Não é possível compilar um programa C em um Mac após a atualização para o Catalina 10.15



xcode macos (5)

TL; DR

Parece que a Apple considera /usr/include como algo que foi o caminho do dodó - está extinto - ou talvez seja como o Parrot Monty Python.

Usar o GCC fornecido pela Apple (na verdade, é Clang com qualquer outro nome, como mostra a informação da versão) ou Clang evita problemas. Ambos /usr/bin/gcc e /usr/bin/clang encontrarão as bibliotecas do sistema quatro níveis de diretório abaixo:

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

Se você criar seu próprio GCC ou outro compilador, (provavelmente) precisará configurá-lo para encontrar as bibliotecas do sistema no diretório do aplicativo Xcode.

Explorações

Imediatamente após a atualização, executei o XCode 11.0. Ele queria instalar alguns componentes extras, então eu deixei. No entanto, isso não restabeleceu /usr/include ou o diretório em /Library .

Um dos outros conselhos da pergunta anterior era executar:

xcode-select --install

Ao fazer isso, alegou que baixou os utilitários de linha de comando e garantiu a presença de /usr/bin/gcc e /usr/bin/clang etc. Essa é uma etapa útil (embora eu não tenha verificado definitivamente se eles estavam 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
$

Usando /usr/bin/gcc , agora é possível 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
$

No entanto, /usr/include ainda está ausente. Há um diretório em /Library agora:

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

Nem o System nem o diretório Library contêm algo muito promissor.

Quando tudo mais falhar, leia o manual

Próxima etapa - encontre e leia as notas de versão:

Não há informações lá relacionadas a isso. Portanto, a probabilidade é (AFAICS, depois de apenas uma ou duas horas de esforço) que a Apple não apóie mais /usr/include - embora ainda tenha um /usr/lib totalmente carregado (sem /lib ).

Hora de verificar outra compilação com a opção GCC -v adicionada (no makefile que usei, a configuração de UFLAGS adiciona a opção à linha de comando do 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
$

As informações principais nessa tempestade de dados são:

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

Esse é efetivamente o diretório 'root' para a compilação; portanto, deve haver subdiretórios para usr e 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
$

Isso mostra que o nome do diretório de uma milha e totalmente memorável contém os cabeçalhos C e POSIX padrão, além de extras específicos da Apple.

O /usr/local/ parece estar intacto; o aviso sobre usr/local/include não existente no -isysrootdir é inofensivo (e não é visível sem a opção -v ).

https://ffff65535.com

Há uma pergunta anterior Não é possível compilar o programa C em um Mac após a atualização para o Mojave , e as respostas para isso cobriram a maioria das variações do que está errado.

Agora - a partir de segunda-feira 2019-10-07 - você pode atualizar para o macOS Catalina 10.15. Mais uma vez, durante a atualização, o /usr/include foi deslumbrado com a atualização, mesmo que o XCode 11.0 tenha sido instalado antes da atualização (do Mojave 10.14.6) para a Catalina. Consequentemente, os compiladores criados para esperar que exista um /usr/include não funcionam mais.

A principal etapa recomendada para os problemas do Mojave - usando o comando:

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

não funciona fora do portão porque o diretório /Library/Developer/CommandLineTools/Packages/ não existe (portanto, ainda não há um arquivo .pkg a ser aberto).

Existe uma maneira (oficial) boa de criar e preencher o diretório /usr/include ?


A dependência apue.h ainda estava ausente em meu /usr/local/include após seguir a resposta de Komol Nath Roy nesta pergunta.

Eu baixei a dependência manualmente do git e coloquei em /usr/local/include


Defina as variáveis Make implícitas a seguir para apontar para o local onde os cabeçalhos estão agora localizados para as Ferramentas de Linha de Comando do 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

A opção -isysroot atualiza o local dos arquivos raiz longe do diretório raiz do sistema / .

Portanto, isso garante que os arquivos /usr/* comuns sejam encontrados em seu novo local.

Ou seja, os arquivos em /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk agora são encontrados. Esses arquivos são:

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

Eu sou um novato no compilador C ++ para R no OSX e tive o mesmo problema que o C ++ não conseguiu encontrar o cabeçalho após a atualização do SO ( falta math.h embora ele estivesse lá ). Segui as instruções de https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ mas nada mudou.

Finalmente, funcionou para mim depois que eu reinstalei a CLI do Xcode

xcode-select --install

e altere os sinalizadores para Var, conforme sugerido pela @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

Para mim, adicionar o seguinte caminho ao CPATH resolveu o problema:

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




macos-catalina