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


64

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/includediretório 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/includediretório 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 .pkgarquivo para abrir).

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


Você não precisa /usr/includeusar as ferramentas de desenvolvedor da Apple com o Xcode atual da Apple. Os cabeçalhos e tais estão em Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (É necessário manter cabeçalhos em diretórios diferentes para oferecer suporte a várias plataformas de destino, e é bom não /usr/includegarantir que nenhuma compilação use acidentalmente arquivos dele ao direcionar uma versão diferente do sistema host.) O que xcode-select -pmostra o caminho para o diretório ativo do desenvolvedor?
Eric Postpischil

Criei o GCC 9.2.0 (no Mojave) e ele espera poder usá /usr/include-lo nos cabeçalhos do sistema. Eu gostaria de poder usá-lo ainda, embora eu suspeite que a Apple finalmente jogou fora os últimos vestígios de compatibilidade com os sistemas Unix herdados (até certo ponto, a escrita estava na parede com o sistema necessário para fazer o Mojave funcionar '). Nesse caso, eu provavelmente tenho que reconstruir o GCC especificando a localização atual dos cabeçalhos do sistema de alguma forma - bashing manual para saber como configurar o GCC.
Jonathan Leffler

11
@ JonathanLeffler: Após a atualização para a catalina, também enfrento o problema de que alguns arquivos (como stdlib.h) estão ausentes e são usados ​​pelo pacote de software R ao instalar pacotes R. Tentei o mesmo que você para o macOS_10.14, mas isso não é mais possível. GCC, c ++ ou o que estiver instalado em / Library / Developer / CommandLineTools / usr / bin, mas R não sabe. O que eu posso fazer?
sebastiann

Desde que atualizei para Catalina há uma semana, tornei-me vítima do agora notório problema de 'digitação dupla' nos novos teclados Mac, mudei para zsh, mudei de idéia e decidi voltar ao bash e atualize para o bash5.0, agora estou aqui porque não consigo compilar o bash5.0. Gostaria de saber se a resposta correta para esse problema não é apenas cortar minhas perdas e mudar para o Arch?
DryLabRebel 30/10/19

Uma maneira de contornar o problema é usar os compiladores Xcode - se estiverem instalados, eles sabem onde encontrar os cabeçalhos do sistema. A técnica CPATH na resposta aceita também parece funcionar bem. Ainda não sofri em um Mac a "digitação dupla" (que eu saiba). Meu iPhone decidiu que eu digitei todo tipo de coisa interessante, mas até agora, toque em madeira, meu MacBook Pro foi bom.
Jonathan Leffler

Respostas:


30

Para mim, adicione o seguinte caminho para CPATHresolver o problema:

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

Eu tentei adicionar o CPATH; no entanto, ainda estou recebendo esse mesmo erro. apenas tentando fazer um simples cout << "olá";
Jon Pellant

11
Quando tentei isso, funcionou em um teste casual com um GCC 9.2.0 construído no Mojave usando o que é agora o Xcode 11.1 - obrigado.
Jonathan Leffler

Isso funcionou para mim com o GCC 9.2.0_1
Sandeep

5
Se você estiver usando as ferramentas de linha de comando em vez do Xcode.app, useexport CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
nalzok 19/10/19

Uma peculiaridade - eu tenho um código que foi iniciado#include <stdlib.h>e depois falhou ao compilar as reclamações: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);- No entanto, quando adiciono#include <ctype.h>antes#include <stdlib.h>, ele compila OK. Ainda resolvendo o que isso significa e como lidar com isso automaticamente.
Jonathan Leffler

48

Antes de prosseguir, instale as ferramentas de linha de comando do xcode.

xcode-select --install

Na verdade, você pode fazer isso! Na verdade, todos os cabeçalhos C são encontrados aqui nesta pasta:

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

Só precisamos criar um link simbólico para todos os arquivos de cabeçalho nesta pasta:

/usr/local/include/

Funcionou para mim! a seguinte linha de comando cuidará de todos os problemas:

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

Você receberá algum aviso. Alguns dos cabeçalhos já existem, assim:

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 para ignorar. Isso é tudo.


11
Sim, suponho que isso seja possível - obrigado pela sugestão. Realmente não corresponde aos meus requisitos de 'higiene do sistema' (por exemplo, os cabeçalhos duplicados) e a /usr/local/hierarquia de diretórios é destinada ao software local e não ao software do sistema. Na IMO, os cabeçalhos devem estar presentes /usr/includee a Apple está apenas sofrendo.
Jonathan Leffler

11
Existe uma maneira de contornar, pode funcionar, você pode tentar. No modo de recuperação, desative o SIP e monte o /no modo de gravação. Em seguida, preencha a /usr/includepasta. É porque na 10.15, o sistema é montado como modo somente leitura. sem desativar o SIP, você não poderá montar o volume do sistema.
Roy

@KomolNathRoy: obrigado por suas dicas. Isso funcionou muito bem para mim. Finalmente, eu poderia instalar todos os meus pacotes desejados no software estatístico R, porque nenhum R encontra tudo o que precisa para a instalação.
Sebastiann

7
Esta solução funcionou para mim no Catalina 10.15
Matthew Barbara

2
Desabilitar o SIP não é aceitável para mim, mesmo como uma medida temporária.
Jonathan Leffler

22

TL; DR

Parece que a Apple considera /usr/includealgo como o dodô - está extinto - ou talvez seja como o papagaio de 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/gcce /usr/bin/clangencontrarã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/includeou 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 que /usr/bin/gcce /usr/bin/clangetc estavam presentes. 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/includeainda está faltando. Há um diretório /Libraryagora:

$ 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 diretório Systemnem o Librarydiretório 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 suporta mais /usr/include- embora ainda tenha um totalmente carregado /usr/lib( /libembora).

Hora de verificar outra compilação com a opção GCC -vadicionada (no makefile que usei, a configuração UFLAGSadiciona 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 nevasca de dados são:

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

Esse é efetivamente o diretório 'raiz' da compilação, portanto, deve haver subdiretórios nesse usre para 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/diretório anterior parece estar intacto; o aviso de usr/local/includenão existir no âmbito -isysrootdiré inofensivo (e não é visível sem a -vopção).


Desculpe, não pudemos seguir sua sugestão. Estou recebendo o mesmo erro com a atualização catalina. Com o vscode, não consegui criar aplicativos C ++ e wchar.hnão obtive erro. Tentei incluir esta pasta -I / Applications / Xcode.app / Contents / Developer / Platforms / MacOSX.platform / Developer / SDKs / MacOSX.sdk / usr / include e iam recebendo outros erros como sobre a falta de símbolos para "error: no member chamado 'isless' no espaço para nome global "
user3279954 10/10/19

Ativado --verboseno arquivo de tarefas e percebeu que o código vs está olhando para a /usr/include/c++/v1/pasta que não existe mais agora na catalina. Adicionada a seguinte pasta, juntamente com o sdk include acima e agora funciona. "-I / Library / Developer / CommandLineTools / usr / include / c ++ / v1 /",
user3279954 10/10/19

@trojanfoe - Eu prefiro o SCCS, mas em 1999 não estava claro se o SCCS funcionaria corretamente após o Y2K (e não havia uma boa implementação de código aberto do SCCS que eu conhecia), então mudei com relutância para o RCS.
Jonathan Leffler 10/10

Wow: D Então, de qualquer maneira, qual é o problema de /usr/includedesaparecer? Sempre fazia parte implicitamente do caminho de inclusão do compilador, para que o usuário nunca precisasse saber sobre ele (além de quando você estava tentando descobrir onde algo foi declarado). Clang faz o mesmo com o caminho do SDK abaixo, Xcode.appportanto o efeito líquido é o mesmo.
trojanfoe

11
@trojanfoe: um problema (meu principal problema) com o /usr/includeAWOL desaparecido é que, se você construiu seu próprio GCC a partir da fonte, provavelmente foi compilado para encontrar os cabeçalhos do sistema /usr/includee, portanto, as compilações falham. Eu quero usar o último GCC, bem como Clang. Estou feliz em usar o Clang da Apple, mas não estou feliz em usar o Clang da Apple disfarçado de GCC - não é o mesmo que GCC. Ainda não elaborei uma receita para criar o GCC com os cabeçalhos do sistema realocados. (Acho que --with-native-system-header-dir="${XCODE_HDR}"é parte da resposta, mas não é, no entanto, a resposta completa.)
Jonathan Leffler

7

Defina as seguintes Makevariáveis implícitas 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 -isysrootopção atualiza o local dos arquivos raiz longe do diretório raiz do sistema /.

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

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

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

Nos meus makefiles (e na maioria dos outros makefiles que vejo), CFLAGSé muito mais complexo que uma única opção - a -isysrootopção precisaria ser 'além de' as outras configurações (muitas outras configurações). Pode haver um kernel de uma idéia aqui (passar a -isysrootopção e o local sob /Library/Developer/…), mas iria precisar de algum polimento antes de estar pronto para o horário nobre.
Jonathan Leffler

@JonathanLeffler Usar em export CFLAGS+=-isysroot ...vez disso funcionará para esse caso de uso. Essa é a única solução que funcionou para mim (no Mojave (10.14) com o SDK da Catalina (10.15). Não tenho o .pkgarquivo que todos falam, apesar de minhas ferramentas de linha de comando e XCode estarem atualizadas.
Norswap 04/12/19

@ Norwap - há uma enorme diferença entre o uso de CFLAGS=…e CFLAGS+=….
Jonathan Leffler

@JonathanLeffler concordou. Atualizei a resposta para usar +=. Obrigado @Norswap.
coatless

11
Como alternativa, descobri que definir SDKROOTo mesmo valor sdk ( /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) também funcionará para mim!
Norswap

4

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

1

No meu caso, eu parecia ter llvme gcctambém instalado usando homebrew. Quando os removi e, portanto, confiei totalmente no clang do macOS, ele pôde encontrar os cabeçalhos e a compilação funcionando novamente.


0

dependência apue.h ainda estava faltando no meu /usr/local/includedepois de seguir resposta Komol Nath Roy nesta pergunta.

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


O cabeçalho apue.hvem de W Richard Stevens, Stephen A Rago Programação Avançada no Ambiente Unix, 3º Edn 2013. AFAIK, nunca foi fornecido pela Apple como cabeçalho do sistema. (Não está na /usr/includeminha máquina que ainda executa o Mojave.) Se ele já foi instalado /usr/include, provavelmente foi criado manualmente, em vez de ser fornecido pela Apple. Como tal, ele deveria ter sido instalado /usr/local/includeanteriormente.
Jonathan Leffler

Desculpe minha pergunta ingênua, mas acabei de colocar minhas mãos em C ++ esta semana. As dependências / cabeçalhos são gerenciados manualmente em c ++? se sim, devo colocar todas as dependências / cabeçalhos mencionados /usr/include?
Matthew Barbara

11
Q1: mais ou menos. Depende um pouco do que você quer dizer, mas você precisa se preocupar com dependências e cabeçalhos para C ou C ++ se os cabeçalhos não forem padrão nas máquinas com as quais você está trabalhando. Então vem a pergunta - o que é padrão? E a melhor resposta que pode ser dada é "depende" e depende de muitos fatores - incluindo 'plataforma' (O / S, compilador). Q2 é "Não, você normalmente não deve colocar nada /usr/include" - use em seu /usr/local/includelugar. Geralmente, é mais seguro para sair /usr/includee /usr/libsozinho, e adicionar sob o material /usr/localem seu lugar.
Jonathan Leffler

0

A solução foi mais simples do que eu pensava. Instale clang / llvm.

brew install llvm

Então precisamos criar links simbólicos.

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

Dependendo da sua versão do llvm, modifique os comandos acima.

Agora, você pode compilar programas C ++ sem passar nenhum sinalizador personalizado.

clang++ hello.cpp


0

Para mim, funciona bem como 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
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.