Catalina C ++: Usar cabeçalhos <cmath> gera erro: nenhum membro chamado 'signbit' no espaço para nome global


16

Após atualizar para o Catalina a partir do Mojave, Configurando: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk no env.

Não consigo compilar um programa que use o <cmath>cabeçalho.

Tentei alterar CFLAGS, CCFLAGS, CXXFLAGS para apontar para o local do MacOSSDK que não muda nada

Scanning dependencies of target OgreMain
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f OgreMain/CMakeFiles/OgreMain.dir/build.make OgreMain/CMakeFiles/OgreMain.dir/build
[  0%] Building CXX object OgreMain/CMakeFiles/OgreMain.dir/src/OgreASTCCodec.cpp.o
cd /Users/roman/Downloads/ogre-1.12.2/build/OgreMain && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -DOgreMain_EXPORTS -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OSX -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/include/Threading -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/src -I/Users/roman/Downloads/ogre-1.12.2/build/Dependencies/include -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/include -I/Users/roman/Downloads/ogre-1.12.2/build/include -I/Users/roman/Downloads/ogre-1.12.2/OgreMain -isystem /usr/local/include  -Wall -Winit-self -Wcast-qual -Wwrite-strings -Wextra -Wundef -Wmissing-declarations -Wno-unused-parameter -Wshadow -Wno-missing-field-initializers -Wno-long-long -Wno-inconsistent-missing-override  -msse -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   -std=c++11 -o CMakeFiles/OgreMain.dir/src/OgreASTCCodec.cpp.o -c /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreASTCCodec.cpp
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreASTCCodec.cpp:29:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreStableHeaders.h:40:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/include/OgrePrerequisites.h:309:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/include/OgreStdHeaders.h:10:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9: error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:315:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:316:9: error: no member named 'isfinite' in the global namespace; did you mean 'finite'?
using ::isfinite;

por exemplo, a macro: islessestá presente no espaço para nome global e no meu computador:

 cat math.h | grep "isless"

#define isless(x, y) __builtin_isless((x),(y))
#define islessequal(x, y) __builtin_islessequal((x),(y))
#define islessgreater(x, y) __builtin_islessgreater((x),(y))
  pwd
/usr/local/include

Até o cabeçalho cmath o inclui:

 cat /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath | grep "math.h"
#include <math.h>

E minha linha de comando tem a opção -isystem /usr/local/include

Isso deve funcionar ...


Corresponde a xcode-select -ponde o Xcode está localizado? Você pode alterar o código para using std::signbit;, da mesma forma para os outros? Você está compilando como C ++ 11 ou posterior?
Eljay

Compilando como C ++ 11. Não consigo alterar o código, são dependências externas! sim xcode-select -pcorresponde a onde XCodeestá localizado.
roman Sztergbaum 30/10/19

Isso não é bom. O código está tentando fazer using ::signbit;e o símbolo não está no espaço para nome global, está no std::espaço para nome. Presumo o mesmo com os outros (não os persegui).
Eljay

Respostas:


7

Estou curioso: Qual compilador você está usando? Qual é o valor de CMAKE_OSX_SYSROOT?

Estou bastante convencido de que isso é resultado de um erro CMAKE_OSX_SYSROOT. Eu tive o problema que você está descrevendo ao usar ligações python para clang (onde o CMake não gerencia a chamada do compilador), mas consegui recriar o erro no CMake fazendo:

set(CMAKE_OSX_SYSROOT "")  # Reset.

Resolvi meu problema seguindo as respostas a esta pergunta: Não é possível compilar pacotes R com código c ++ após a atualização para o macOS Catalina .

Para resumir: Na Catalina, /usr/includeé eliminado e protegido pelo SIP. Portanto, qualquer projeto que espere que os cabeçalhos C sejam encontrados lá falhará na compilação. Se bem me lembro, a Apple recomenda a relatórios de bugs arquivos para projetos que esperam os cabeçalhos C no /usr/include.

Você deve apontar o sistema de compilação do código que está tentando compilar para os cabeçalhos corretos:

(1) Verifique se o Xcode está atualizado. Não há como dizer o que um Xcode desatualizado na Catalina pode fazer com o seu ambiente de construção.

(2) Use o -isysroot /sdk/pathsinalizador do compilador, onde /sdk/pathé o resultado de xcrun --show-sdk-path. Não sei ao certo qual é a melhor prática do CMake, mas tente fazer

set(CMAKE_OSX_SYSROOT /sdk/path)

ou

set(CMAKE_CXX_FLAGS "[...] -isysroot /sdk/path")

Se isso resolver o problema, você pode procurar uma maneira melhor de fazer isso no CMake.

Obviamente, se você é aventureiro, também pode desativar o SIP, conforme sugerido na resposta à minha pergunta: / usr / include ausente no macOS Catalina (com Xcode 11)


11
set(CMAKE_OSX_SYSROOT ...)entra CMakeLists.txt, não a concha.
mkl 21/03

6

Estou tendo o mesmo problema ao tentar segmentar o iOS (no meu MacBook Air e no corredor GitHub Actions) e aqui estão mais algumas reflexões sobre o problema, embora eu não esteja familiarizado o suficiente com o ecossistema da Apple para sugerir uma solução adequada. A linha de comando original vinha do CMake no cpprestsdk, mas depois que eu a reduzi ao essencial, aqui está uma breve reprodução.

  1. Crie um arquivo cmath-bug.cppcom a única linha:
    #include <cmath>
  1. Executar (as novas linhas na frente de alguns argumentos são para facilitar a leitura, remova-as)
clang -v -x c++ -target arm64-apple-ios13.2 -fcolor-diagnostics -std=c++11 -stdlib=libc++ 
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk 
-isystem  /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include
-c cmath-bug.cpp

Quando o executo, familiarizo-me com muitos que enfrentam o mesmo problema:

Apple clang version 11.0.0 (clang-1100.0.33.16)
Target: arm64-apple-ios13.2
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 arm64-apple-ios13.2.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name cmath-bug.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=13.2 -target-cpu cyclone -target-feature +fp-armv8 -target-feature +neon -target-feature +crypto -target-feature +zcm -target-feature +zcz -target-feature +sha2 -target-feature +aes -target-abi darwinpcs -fallow-half-arguments-and-returns -dwarf-column-info -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 530 -v -coverage-notes-file /Users/myuser/Projects/C++/cmath-bug.gcno -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk -isystem /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include -stdlib=libc++ -internal-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1 -Wno-framework-include-private-from-public -Wno-atimport-in-framework-header -Wno-extra-semi-stmt -Wno-quoted-include-in-framework-header -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/myuser/Projects/C++ -ferror-limit 19 -fmessage-length 204 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=ios-13.2.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o cmath-bug.o -x c++ cmath-bug.cpp
clang -cc1 version 11.0.0 (clang-1100.0.33.16) default target x86_64-apple-darwin19.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/Library/Frameworks"
ignoring duplicate directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
 /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/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/System/Library/Frameworks (framework directory)
End of search list.
In file included from cmath-bug.cpp:1:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:318:9: error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:319:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:320:9: error: no member named 'isfinite' in the global namespace; did you mean 'finite'?
using ::isfinite;
      ~~^

Os únicos 2 diretórios de inclusão que passo na minha linha de comando original existem e são:

$ ls -alF /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk
lrwxr-xr-x  1 root  wheel    12B Dec 17 11:54 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk@ -> iPhoneOS.sdk
$ ls -alF /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include
total 2160
drwxr-xr-x  169 root  wheel   5.3K Dec 17 12:07 ./
drwxr-xr-x    5 root  wheel   160B Nov  4 19:22 ../
 ...
-rw-r--r--    9 root  wheel    32K Nov  4 19:52 math.h
 ...

Mas as partes interessantes aqui são os diretórios de inclusão inexistentes que ele relata, bem como os diretórios de inclusão que ele acaba pesquisando eventualmente e sua ordem. Meu palpite é que diretórios adicionais não mencionados na linha de comando são inseridos pelo driver do Apple Clang com base em alguma lógica específica da Apple.

Você pode ver pelo erro relatado que o <cmath>cabeçalho está localizado em: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmathe na linha 304 dele, você pode ver:

#include <__config>      // Line 304
#include <math.h>        // This one ends up causing troubles
#include <__cxx_version>

A julgar pelo fato de que nessa mesma pasta /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/existe um arquivo math.hque fornece as definições necessárias, por exemplo:

#include <__config>

#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
#pragma GCC system_header
#endif

#include_next <math.h>

#ifdef __cplusplus

// We support including .h headers inside 'extern "C"' contexts, so switch
// back to C++ linkage before including these C++ headers.
extern "C++" {

#include <type_traits>
#include <limits>

// signbit

#ifdef signbit

template <class _A1>
_LIBCPP_INLINE_VISIBILITY
bool
__libcpp_signbit(_A1 __lcpp_x) _NOEXCEPT
{
    return signbit(__lcpp_x);
}

#undef signbit

template <class _A1>
inline _LIBCPP_INLINE_VISIBILITY
typename std::enable_if<std::is_floating_point<_A1>::value, bool>::type
signbit(_A1 __lcpp_x) _NOEXCEPT
{
    return __libcpp_signbit((typename std::__promote<_A1>::type)__lcpp_x);
}

...

#elif defined(_LIBCPP_MSVCRT)
...
#endif  // signbit

os autores <cmath>esperavam que a math.hpartir dessa mesma pasta fosse incluída primeiro e, em seguida, a #include_next <math.h>diretiva encontrasse o sistema específico math.h. Isso não é o que está acontecendo na realidade, no entanto.

Se você observar as 2 primeiras entradas nos diretórios pesquisados:

#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1

você vê que o diretório de inclusão específico do sistema acaba acima do diretório da biblioteca padrão injetado por Clang, e é por isso que o específico do sistema math.hestá sendo encontrado, não aquele na mesma pasta que o restante dos cabeçalhos da biblioteca padrão. Provavelmente, esse é o caso, porque se eu adicionar explicitamente o diretório include da biblioteca padrão à minha linha de comando ANTES dos outros dois diretórios, -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1o problema desaparecerá e eu posso compilar o arquivo. Não é isso que o driver de Clang ou o que mais está envolvido aqui faz automaticamente: ele adiciona esse diretório de biblioteca padrão via -internal-system(não sabe qual é a semântica desse sinalizador interno) e o adiciona APÓS o diretório do sistema.

Agora, se você olhar para a lista de diretórios ignorados, a primeira entrada nessa lista é:

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include/c++/v1"

dos quais a c++/v1parte final não existe na minha máquina, me perguntando se a instalação do iPhone SDK deveria criar um link simbólico c++dentro da parte existente do caminho para apontar para o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++diretório e fazer com que tudo funcionasse.

Enfim, é isso que eu acho que está acontecendo e me pergunto se alguém sabe como consertar isso corretamente.

Obrigado!

PS Para o contexto:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcrun --show-sdk-path -sdk iphoneos13.2
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk

2

Usando o comando:

gcc -Wp,-v -E -

minha #include <...> sequência de pesquisa:

 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.1/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks (framework directory)

O motivo do erro #include está descrito abaixo:

 - #include<cmath> resides in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
 - It includes <math.h>.
 - It searches /usr/local/include directory as this is the first directory to search. There is a math.h in "/usr/local/include/c++/9.3.0/" directory
 - It tries to use this.
 - But expectation was to use the math.h of the same directory /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
 - The math.h of /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 include math.h of /usr/local/include using #include_next<math.h>
 - As wrong math.h is included/linked with /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath, the compilation error happens

O conserto:

    1. If we can alter the search order of #include<...> to search /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 at first, it can be fixed.
    2. Using #include</Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h> instead of <math.h> in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath

Eu segui a opção nº 2 e a compilação foi bem-sucedida agora!

E obrigado a Solodon pela resposta detalhada. Eu segui a resposta para corrigir o problema.


Oi Niloy Datta! Sugiro que você edite esta resposta removendo a pergunta desta resposta e inclua apenas quais respostas. Se você tiver uma pergunta, faça separadamente da maneira correta que as perguntas devem ser feitas nesta comunidade.
Tiago Martins Peres 李大仁 30/04

11
@TiagoMartinsPeres 李大仁, removeu-o. Obrigado.
Niloy Datta

Obrigado cara, funcionou para mim. Você conhece uma maneira mais limpa de lidar com esse problema?
Victor Sanchez

1

É possível que sua cópia do Xcode esteja corrompida. Verifique com o código de código:

codesign --verify /Applications/Xcode.app

Isso aconteceu comigo e o problema foi corrompido no Xcode. A reinstalação corrigiu.

Algo havia modificado o seguinte:

file added: /Applications/Xcode-11.3.1-.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/json/__pycache__/scanner.cpython-37.pyc
file added: /Applications/Xcode-11.3.1-.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/json/__pycache__/decoder.cpython-37.pyc
file added: /Applications/Xcode-11.3.1-.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/json/__pycache__/encoder.cpython-37.pyc
file added: /Applications/Xcode-11.3.1-.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/json/__pycache__/__init__.cpython-37.pyc
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/DriverKit19.0.sdk/System/DriverKit/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/include/math.h
file modified: /Applications/Xcode-11.3.1-.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/math.h

math.h estava vazio em todos os lugares acima.


1

A análise do @ solodon está no local. É provável que o problema cmathesteja incluindo a versão errada, com math.hbase na ordem de pesquisa dos arquivos de cabeçalho. Pelo menos, é o que estava acontecendo comigo quando estava recebendo o mesmo erro.

Examine a saída do seu compilador #include <...> search starts here:. Você também pode forçar essa saída na linha de comando com (fonte) :

gcc -Wp,-v -E -

Deve ser algo como isto:

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

Observe que os caminhos com Toolchainsvêm antes daqueles com Platforms. Se, no seu caso, a ordem for revertida, você precisará descobrir o que está causando isso na sua configuração. Para mim, era uma configuração explícita CPLUS_INCLUDE_PATHno meu script de login.

Código incorreto:

XCBASE=`xcrun --show-sdk-path`
export CPLUS_INCLUDE_PATH=$XCBASE/usr/include

Isso foi parte da minha tentativa de solucionar o Xcode 11, não fornecendo mais o pacote de instalação para os arquivos de cabeçalho do SDK. Depois de remover esse código, consegui incluir com êxito cmathno meu código C ++.

Se você veio aqui procurando soluções para esse problema, pode precisar de uma solução diferente, mas espero que isso ajude a esclarecer o que parece ser a causa raiz desse problema, ordem do caminho de pesquisa do arquivo de cabeçalho.


0

Eu descobri que dentro do meu projeto eu tenho arquivo math.h. Depois de renomeá-lo, o problema desapareceu. Costuras cmathincluem meu arquivo em vez de sistema.


0

Acabei de receber esse erro ao tentar compilar o gRPC após atualizar recentemente para 10.15.4 e Xcode 11.4 e comecei a examinar todas as soluções oferecidas (aqui e Não é possível compilar um programa C em um Mac após atualizar para o Catalina 10.15 ) , e tentei alguns deles (apesar de não tentar recriar, /usr/includepois isso violaria a separação que a Apple estava tentando criar) - nada parecia funcionar.

Em seguida, observei atentamente as invocações complier reais que o makeprocesso estava produzindo e notei que havia um

-I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include

que estava causando a inclusão incorreta da ordem - remover esse caminho de inclusão explícito permitiu que a compilação fosse bem-sucedida com uma instalação padrão das ferramentas de linha de comando catalina, Xcode e Xcode, como seria de esperar, sem outros sinalizadores de truques / compiladores necessário.


Também encontrei esse problema. Acontece que alguns pkg-configarquivos (por exemplo, libcurl) do Homebrew adicionam esse caminho automaticamente, mesmo se você tiver o Xcode instalado. Isso foi corrigido no Homebrew 2.2.13. Mais detalhes em github.com/Homebrew/brew/issues/5068 ; O PR que corrige isso está no github.com/Homebrew/brew/pull/7331 . TL; DR: atualização homebrew
kkaefer 14/04

Sim, era um antigo homebrew pkg_config para o zlib que ainda estava de alguma forma por aí, o que estava causando isso para mim - apesar de ter um homebrew atualizado e atualmente não ter um zlib instalado de qualquer maneira
pahjbo 16/04

0

Você pode tentar usar o CommandLineTools SDK em vez do XCode.app SDK.

Corrijo esse problema ao compilar o PointCloudLibrary (PCL)

#Check the current sdk
xcrun --show-sdk-path

#Change sdk
sudo xcode-select -s /Library/Developer/CommandLineTools          #Using CommandLineTools SDK
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer   #Using XCode.app SDK

Além disso, reinstale o XCode.app e o CommandLineTools pode ajudar.


0

Resumo: no meu caso, o script de construção estava usando uma versão mais antiga do ios-cmaketoolchain (2.1.2) e atualizá-lo para 3.1.2 corrigiu o problema cmath / math include.

Adaptação do comando nifty proposto por @Ryan H. gcc -Wp,-v -E -para o meu caso (clang, c ++, destino iOs)

clang -x c++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk -Wp, -v -E -

produz dois Catalina, incluindo um virgem, onde apenas a ferramenta já instalada é o XCode 11.14.1:

 clang -cc1 version 11.0.3 (clang-1103.0.32.59) default target x86_64-apple-darwin19.4.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.3/include
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/System/Library/Frameworks (framework directory)
End of search list.

Portanto, o caminho de inclusão correto é o primeiro não ignorado; tudo deve funcionar bem, mas não funcionou. Parece que o problema veio de um comando de inclusão adicional anexado à chamada de compilação pela cadeia de ferramentas ios-cmake:

CompileC /Users/<...>/build.Release.ios/<...>.o <...>.cpp normal arm64 c++ com.apple.compilers.llvm.clang.1_0.compiler
-Isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk <...>
 -I/Users/<...>/Build_iOS/build.Release.ios/build.arm/Binaries/Release/include
 -Isystem /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.4.sdk/usr/include
 -I/Users/<...>/Build_iOS/build.Release.ios/build.arm/src/<...>.build/Release-iphoneos/<...>/DerivedSources/arm64
...

O culpado foi a -Isystem ...linha, o que fará com que a #include <math>linha no arquivo cmath acabe carregando o arquivo errado. Depois de muito tempo tentando consertar os scripts cmake, notei a versão mais antiga do ios-cmake, e atualizá-la teve o 'único' efeito de remover a -Isystemlinha indesejada - todo o resto era quase o mesmo (exceto algumas opções do compilador)

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.