Catalina C ++: Używanie nagłówków <cmath> powoduje błąd: żaden element o nazwie „signbit” w globalnej przestrzeni nazw

16

Po aktualizacji do Catalina z Mojave, Konfiguracja: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk w środowisku.

Nie mogę skompilować programu używającego <cmath>nagłówka.

Próbowałem zmienić CFLAGS, CCFLAGS, CXXFLAGS, aby wskazywały lokalizację MacOSSDK, która niczego nie zmienia

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;

na przykład makro: islessjest obecne w globalnej przestrzeni nazw i na moim komputerze:

 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

Nawet nagłówek cmath zawiera:

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

A moja linia poleceń ma opcję -isystem /usr/local/include

To powinno działać ...

Roman Sztergbaum
źródło
Czy xcode-select -ppasuje do lokalizacji Xcode? Czy możesz zmienić kod using std::signbit;również na inne? Czy kompilujesz jako C ++ 11 lub nowszy?
Eljay
Kompilacja jako C ++ 11. Nie mogę zmienić kodu, to zewnętrzne zależności! tak, xcode-select -pdopasuj gdzie XCodesię znajduje.
Roman Sztergbaum
To nie jest dobrze. Kod próbuje to zrobić, using ::signbit;a symbol nie znajduje się w globalnej przestrzeni nazw, lecz w std::przestrzeni nazw. Przypuszczam, że podobnie jest z innymi (nie ścigałem ich).
Eljay

Odpowiedzi:

7

Jestem ciekawy: jakiego kompilatora używasz? Jaka jest wartość CMAKE_OSX_SYSROOT?

Jestem dość przekonany, że jest to wynikiem zła CMAKE_OSX_SYSROOT. Miałem problem, który opisujesz, używając powiązań Pythona do clang (gdzie CMake nie zarządza wywołaniem kompilatora), ale udało mi się odtworzyć błąd w CMake, wykonując:

set(CMAKE_OSX_SYSROOT "")  # Reset.

Rozwiązałem swój problem, postępując zgodnie z odpowiedziami na to pytanie: Nie można skompilować pakietów R z kodem c ++ po aktualizacji do macOS Catalina .

Podsumowując: Na Catalinie /usr/includejest oczyszczony i chroniony przez SIP. W związku z tym każdy projekt, który spodziewa się tam znaleźć nagłówki C, nie zostanie skompilowany. Jeśli dobrze pamiętam, Apple zaleca plików raportów o błędach do projektów, które oczekują na nagłówki C /usr/include.

Musisz wskazać system kompilacji kodu, który próbujesz skompilować, na właściwe nagłówki:

(1) Upewnij się, że Xcode jest aktualny. Nie wiadomo, co może zrobić przestarzały Xcode na Catalinie w środowisku kompilacji.

(2) Użyj -isysroot /sdk/pathflagi kompilatora, gdzie /sdk/pathjest wynikiem xcrun --show-sdk-path. Nie jestem pewien, jaka jest najlepsza praktyka CMake, ale spróbuj to zrobić

set(CMAKE_OSX_SYSROOT /sdk/path)

lub

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

Jeśli to rozwiąże problem, możesz poszukać lepszego sposobu na zrobienie tego w CMake.

Oczywiście, jeśli masz ochotę na przygodę, możesz również wyłączyć SIP, jak sugerowano w odpowiedzi na moje pytanie: / usr / include missing na macOS Catalina (z Xcode 11)

mkl
źródło
1
set(CMAKE_OSX_SYSROOT ...)wchodzi do CMakeLists.txt, nie do muszli.
mkl
6

Mam ten sam problem podczas próby kierowania na iOS (zarówno na moim MacBooku Air, jak i na gitarze GitHub Actions) i oto kilka innych przemyśleń na ten temat, chociaż nie znam wystarczająco ekosystemu Apple, aby zaproponować właściwe rozwiązanie. Oryginalna linia komend pochodziła z CMake w cpprestsdk, ale kiedy już wszystko sprowadziłem do niezbędności, oto krótkie repro.

  1. Utwórz plik cmath-bug.cppz jedyną linią:
    #include <cmath>
  1. Uruchom (nowe wiersze przed niektórymi argumentami służą do czytania, usuń je)
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

Kiedy go uruchamiam, zapoznaję wielu z tym samym problemem:

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;
      ~~^

Istnieją tylko dwa katalogi, które przekazuję w moim oryginalnym wierszu poleceń i są to:

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

Ale interesujące są tutaj nieistniejące katalogi, które zgłasza, a także katalogi, które ostatecznie przeszukują i ich kolejność. Domyślam się, że dodatkowe katalogi niewymienione w wierszu poleceń są wstawiane przez sterownik Apple Clang w oparciu o logikę specyficzną dla Apple.

Na podstawie zgłoszonego błędu można zobaczyć, że <cmath>nagłówek został znaleziony w: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmatha w wierszu 304 można zobaczyć:

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

Sądząc po tym, że w tym samym folderze /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/znajduje się plik math.hzawierający niezbędne definicje, np .:

#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

autorzy <cmath>spodziewali się, math.hże najpierw z tego samego folderu zostaną dołączeni, a następnie #include_next <math.h>dyrektywa znajdzie specyficzne dla systemu math.h. W rzeczywistości jednak tak się nie dzieje.

Jeśli spojrzysz na pierwsze 2 wpisy w przeszukiwanych katalogach:

#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

widać, że specyficzny dla systemu katalog włączania kończy się powyżej standardowego katalogu biblioteki wstrzykiwanego przez Clanga, dlatego właśnie znajduje się specyficzny dla systemu katalog, a math.hnie ten w tym samym folderze, co pozostałe standardowe nagłówki bibliotek. Jest tak prawdopodobnie dlatego, że jeśli wyraźnie dodam standardowy katalog dołączania biblioteki do mojego wiersza poleceń PRZED pozostałymi dwoma katalogami -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1problem zniknie i będę mógł skompilować plik. Nie robi to automatycznie sterownik Clanga ani cokolwiek innego, co jest tutaj zaangażowane: dodaje ten standardowy katalog biblioteki poprzez -internal-system(nie jestem pewien, co to jest semantyka tej wewnętrznej flagi) i dodaje go PO katalogu systemowym.

Teraz, jeśli spojrzysz na listę ignorowanych katalogów, pierwszy wpis na tej liście to:

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

którego końcowa c++/v1część nie istnieje na moim komputerze, co sprawia, że ​​zastanawiam się, czy instalacja iPhone SDK miała stworzyć symboliczne łącze c++wewnątrz istniejącej części ścieżki, aby wskazać /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++katalog, aby wszystko działało.

W każdym razie to, co myślę, dzieje się i zastanawiam się, czy ktoś wie, jak to naprawić?

Dziękuję Ci!

PS W kontekście:

$ 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
solodon
źródło
1

Możliwe, że twoja kopia Xcode jest uszkodzona. Sprawdź za pomocą kodu:

codesign --verify /Applications/Xcode.app

To mi się przydarzyło, a problem był uszkodzony Xcode. Ponowna instalacja naprawiła to.

Coś zmodyfikowało następujące:

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 był pusty we wszystkich powyższych miejscach.

Rob Napier
źródło
1

Analiza @ solodon jest natychmiastowa. Problem prawdopodobnie cmathdotyczy nieprawidłowej wersji pliku na math.hpodstawie kolejności wyszukiwania plików nagłówkowych. Przynajmniej tak się działo, gdy otrzymywałem ten sam błąd.

Przeskanuj dane wyjściowe kompilatora #include <...> search starts here:. Możesz również wymusić to wyjście z wiersza poleceń za pomocą (source) :

gcc -Wp,-v -E -

Powinno to wyglądać mniej więcej tak:

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

Zauważ, że ścieżki z Toolchainssą przed tymi z Platforms. Jeśli w twoim przypadku kolejność jest odwrócona, musisz dowiedzieć się, co powoduje to w twojej konfiguracji. Dla mnie było to jawne ustawienie CPLUS_INCLUDE_PATHw moim skrypcie logowania.

Obraźliwy kod:

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

To była część mojej próby obejścia Xcode 11, która nie zapewniała już pakietu instalacyjnego dla plików nagłówkowych SDK. Po usunięciu tego kodu udało mi się z powodzeniem dołączyć cmathdo mojego kodu C ++.

Jeśli przyszedłeś tutaj, szukając rozwiązań tego problemu, możesz potrzebować innego rozwiązania, ale mam nadzieję, że to pomoże rzucić światło na to, co wydaje się być główną przyczyną tego problemu, kolejność ścieżek wyszukiwania plików nagłówkowych.

Ryan H.
źródło
1

Za pomocą polecenia:

gcc -Wp,-v -E -

moja #include <...> sekwencja wyszukiwania:

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

Przyczyna błędu #include została opisana poniżej:

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

Poprawka:

    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

Postępowałem zgodnie z opcją nr 2 i kompilacja jest teraz udana!

I dzięki Solodon za szczegółową odpowiedź. Postępowałem zgodnie z odpowiedzią, aby rozwiązać problem.

Niloy Datta
źródło
Cześć Niloy Datta! Sugeruję, aby edytować tę odpowiedź, usuwając pytanie z tej odpowiedzi i dołączając tylko jakie odpowiedzi. Jeśli masz pytanie, zadaj je oddzielnie w odpowiedni sposób, w tej społeczności powinny być zadawane pytania.
Tiago Martins Peres
1
@TiagoMartinsPeres 李大仁, usunąłem go. Dzięki.
Niloy Datta
0

Odkryłem, że w moim projekcie mam plik math.h. Po zmianie nazwy problem zniknął. Szwy cmathzawierają mój plik zamiast systemu.

Gralex
źródło
0

Właśnie dostałem ten błąd podczas próby kompilacji gRPC po niedawnej aktualizacji do 10.15.4 i Xcode 11.4 i zacząłem patrzeć na wszystkie oferowane rozwiązania (tutaj i nie mogę skompilować programu C na Macu po aktualizacji do Catalina 10.15 ) i wypróbowałem kilka z nich (choć nie próbowałem odtworzyć, /usr/includeponieważ naruszałoby to separację, którą Apple próbował stworzyć) - nic nie działało.

Następnie przyjrzałem się dokładnie faktycznym wezwaniom do komplementacji, które makeprodukował ten proces, i zauważyłem, że istnieje wyraźny

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

to ostatecznie spowodowało, że dołączenia wystąpiły w niewłaściwej kolejności - usunięcie tej wyraźnej ścieżki włączania pozwoliło kompilacji na pomyślne zakończenie domyślnej instalacji catalina, Xcode i narzędzi wiersza poleceń Xcode, jak można się spodziewać, żadnych innych flag / trików / kompilatora potrzebne.

pahjbo
źródło
Wpadłem również na ten problem. Okazuje się, że niektóre pkg-configpliki (np. Libcurl) z Homebrew automatycznie dodają tę ścieżkę, nawet jeśli masz zainstalowany Xcode. Zostało to naprawione w Homebrew 2.2.13. Więcej informacji na github.com/Homebrew/brew/issues/5068 ; PR, który to naprawia, znajduje się w github.com/Homebrew/brew/pull/7331 . TL; DR: Aktualizacja homebrew
Kkaefer
Tak, to był stary homebrew pkg_config dla zlib, który wciąż leżał, co powodowało to dla mnie - pomimo posiadania aktualnego homebrew i aktualnie nie zainstalowanego zlib
pahjbo
0

Możesz spróbować użyć CommandLineTools SDK zamiast XCode.app SDK.

Rozwiązuję ten problem podczas kompilacji 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

Ponownie zainstaluj XCode.app i CommandLineTools może pomóc.

Lester Lo
źródło
0

Podsumowanie: w moim przypadku skrypt kompilacji używał starszej wersji ios-cmaketoolchain (2.1.2), a zaktualizowanie go do wersji 3.1.2 naprawiło problem dołączania cmath / matematyki.

Dostosowanie fajnego polecenia zaproponowanego przez @Ryan H. gcc -Wp,-v -E -w moim przypadku (clang, c ++, iOs target)

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

daje dwie Cataliny, w tym dziewiczą, w której jedynym zainstalowanym narzędziem jest 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.

Więc poprawna ścieżka dołączania jest pierwszą niezignorowaną, wszystko powinno działać OK, ale nie zadziałało. Wygląda na to, że problem pochodzi z dodatkowego polecenia dołączania dołączonego do wywołania kompilacji przez łańcuch narzędzi 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
...

Winowajcą była -Isystem ...linia, która spowoduje, że #include <math>linia w pliku cmath skończy się ładowaniem niewłaściwego pliku. Po wielu próbach poprawiania skryptów cmake zauważyłem starszą wersję ios-cmake, a jej aktualizacja miała „jedyny” efekt usunięcia niechcianej -Isystemlinii - wszystko inne było prawie takie samo (oprócz kilku opcji kompilatora)

Spikegee
źródło