Catalina C ++: Die Verwendung von <cmath> -Headern führt zu einem Fehler: Kein Mitglied mit dem Namen 'signbit' im globalen Namespace

16

Nach dem Upgrade von Mojave auf Catalina, Setup: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk in der Umgebung.

Ich kann kein Programm kompilieren, das den <cmath>Header verwendet.

Ich habe versucht, CFLAGS, CCFLAGS, CXXFLAGS so zu ändern, dass sie auf den MacOSSDK-Speicherort verweisen, der nichts ändert

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;

Zum Beispiel das Makro: isless im globalen Namespace und auf meinem Computer vorhanden:

 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

Sogar der cmath-Header enthält Folgendes:

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

Und meine Kommandozeile hat die Option -isystem /usr/local/include

Das sollte funktionieren...

römischer Sztergbaum
quelle
Stimmt xcode-select -püberein, wo sich Xcode befindet? Können Sie den Code ändern using std::signbit;, ebenfalls für die anderen? Kompilieren Sie als C ++ 11 oder höher?
Eljay
Kompilieren als C ++ 11. Ich kann den Code nicht ändern, es handelt sich um externe Abhängigkeiten! ja xcode-select -pübereinstimmen wo XCodebefindet sich.
Roman Sztergbaum
Das ist nicht gut. Der Code versucht dies zu tun using ::signbit;und das Symbol befindet sich nicht im globalen Namespace, sondern im std::Namespace. Ich nehme ebenfalls mit den anderen an (ich habe sie nicht verfolgt).
Eljay

Antworten:

7

Ich bin gespannt: Welchen Compiler verwenden Sie? Was ist der Wert von CMAKE_OSX_SYSROOT?

Ich bin ziemlich davon überzeugt, dass dies das Ergebnis eines Unrechts ist CMAKE_OSX_SYSROOT. Ich hatte das Problem, das Sie beschreiben, wenn Sie Python-Bindungen für Clang verwenden (wobei CMake den Compiler-Aufruf nicht verwaltet), aber ich habe es geschafft, den Fehler in CMake folgendermaßen neu zu erstellen:

set(CMAKE_OSX_SYSROOT "")  # Reset.

Ich habe mein Problem gelöst, indem ich den Antworten auf diese Frage gefolgt bin: R-Pakete mit C ++ - Code können nach dem Update auf macOS Catalina nicht kompiliert werden .

Zusammenfassend: Auf Catalina /usr/includewird durch SIP gelöscht und geschützt. Daher kann jedes Projekt, das erwartet, dass die C-Header dort gefunden werden, nicht kompiliert werden. Wenn ich mich richtig erinnere, empfiehlt Apple, Fehlerberichte für Projekte einzureichen, in denen C-Header erwartet werden /usr/include.

Sie müssen das Build-System des Codes, den Sie kompilieren möchten, auf die richtigen Header verweisen:

(1) Stellen Sie sicher, dass Xcode auf dem neuesten Stand ist. Es ist nicht abzusehen, was ein veralteter Xcode auf Catalina für Ihre Build-Umgebung tun könnte.

(2) Verwenden Sie das -isysroot /sdk/pathCompiler-Flag, wobei /sdk/pathdas Ergebnis von ist xcrun --show-sdk-path. Ich bin mir nicht sicher, was CMakes Best Practice ist, aber versuchen Sie es

set(CMAKE_OSX_SYSROOT /sdk/path)

oder

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

Wenn dies das Problem löst, möchten Sie möglicherweise nach einer besseren Möglichkeit suchen, dies in CMake zu tun.

Wenn Sie abenteuerlustig sind, können Sie natürlich auch SIP deaktivieren, wie in der Antwort auf meine Frage vorgeschlagen: / usr / include fehlt unter macOS Catalina (mit Xcode 11)

mkl
quelle
1
set(CMAKE_OSX_SYSROOT ...)geht in CMakeLists.txt, nicht die Schale.
mkl
6

Ich habe das gleiche Problem beim Versuch, auf iOS abzuzielen (sowohl auf meinem MacBook Air als auch auf GitHub Actions Runner). Hier sind einige weitere Gedanken zu diesem Problem, obwohl ich mit dem Apple-Ökosystem nicht vertraut genug bin, um eine geeignete Lösung vorzuschlagen. Die ursprüngliche Befehlszeile kam von CMake in cpprestsdk, aber sobald ich sie auf das Wesentliche reduziert habe, ist hier ein kurzer Repro.

  1. Erstellen Sie eine Datei cmath-bug.cppmit der einzigen Zeile darin:
    #include <cmath>
  1. Ausführen (Zeilenumbrüche vor einigen Argumenten dienen der Lesbarkeit, entfernen Sie sie)
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

Wenn ich es starte, werde ich vielen vertraut, die mit dem gleichen Problem konfrontiert sind:

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

Die einzigen 2 Include-Verzeichnisse, die ich an meine ursprüngliche Befehlszeile weitergebe, sind und sind:

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

Das Interessante dabei sind jedoch die nicht vorhandenen Include-Verzeichnisse, die gemeldet werden, sowie die Include-Verzeichnisse, die letztendlich durchsucht werden, und deren Reihenfolge. Ich vermute, dass zusätzliche Verzeichnisse, die nicht in der Befehlszeile aufgeführt sind, vom Apple Clang-Treiber basierend auf einer Apple-spezifischen Logik eingefügt werden.

Sie können dem gemeldeten Fehler entnehmen, dass der <cmath>Header gefunden wird in: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmathund in Zeile 304 davon können Sie sehen:

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

Gemessen an der Tatsache, dass sich in demselben Ordner /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/eine Datei befindet math.h, die die erforderlichen Definitionen enthält, z.

#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

Die Autoren von <cmath>erwarteten, math.hdass derselbe Ordner zuerst aufgenommen wird und dann die #include_next <math.h>Direktive die systemspezifische findet math.h. Das ist jedoch nicht das, was in der Realität passiert.

Wenn Sie sich die ersten beiden Einträge in den gesuchten Verzeichnissen ansehen:

#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

Sie sehen, dass das systemspezifische Include-Verzeichnis über dem von Clang injizierten Standardbibliotheksverzeichnis liegt, weshalb das systemspezifische Verzeichnis math.hgefunden wird und nicht das im selben Ordner wie die übrigen Standardbibliotheksheader. Dies ist wahrscheinlich der Fall, weil -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1das Problem behoben ist und ich die Datei kompilieren kann, wenn ich das Standardbibliotheks-Include-Verzeichnis explizit zu meiner Befehlszeile vor den beiden anderen Verzeichnissen hinzufüge . Dies ist nicht das, was Clangs Treiber oder was auch immer hier involviert ist, automatisch tut: Er fügt das Standardbibliotheksverzeichnis über hinzu -internal-system(nicht sicher, wie die Semantik dieses internen Flags lautet ) und fügt es NACH dem Systemverzeichnis hinzu.

Wenn Sie sich nun die Liste der ignorierten Verzeichnisse ansehen, lautet der allererste Eintrag in dieser Liste:

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

Der nachfolgende c++/v1Teil ist auf meinem Computer nicht vorhanden, sodass ich mich frage, ob die iPhone SDK-Installation einen symbolischen Link c++innerhalb des vorhandenen Teils des Pfads erstellen sollte, der auf das /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++Verzeichnis verweist, damit das Ganze funktioniert.

Wie auch immer, das, was ich denke, passiert und ich frage mich, ob jemand weiß, wie man das richtig behebt?

Vielen Dank!

PS Für den Kontext:

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

Verwenden des Befehls:

gcc -Wp,-v -E -

meine #include <...> Suchsequenz:

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

Der Grund für den Fehler #include wird unten beschrieben:

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

Die Reparatur:

    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

Ich habe die Option Nr. 2 befolgt und der Build ist jetzt erfolgreich!

Und danke an solodon für die ausführliche Antwort. Ich folgte der Antwort, um das Problem zu beheben.

Niloy Datta
quelle
Hallo Niloy Datta! Ich empfehle Ihnen, diese Antwort zu bearbeiten, indem Sie die Frage aus dieser Antwort entfernen und nur die Antworten angeben. Wenn Sie eine Frage haben, stellen Sie diese separat in der richtigen Weise. Fragen sollten in dieser Community gestellt werden.
Tiago Martins Peres 30
1
@TiagoMartinsPeres 李大仁, entfernt. Vielen Dank.
Niloy Datta
Danke Mann, es hat bei mir funktioniert. Kennen Sie einen saubereren Weg, um mit diesem Problem umzugehen?
Victor Sanchez vor
1

Möglicherweise ist Ihre Kopie von Xcode beschädigt. Überprüfen Sie mit Codesign:

codesign --verify /Applications/Xcode.app

Dies ist mir passiert und das Problem war Xcode beschädigt. Neuinstallation behoben.

Etwas hatte Folgendes geändert:

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 war an allen oben genannten Stellen leer.

Rob Napier
quelle
1

Die Analyse von @ solodon ist genau richtig. Das Problem ist wahrscheinlich, dass die cmathDatei die falsche Version von enthältmath.h basierend auf der Suchreihenfolge der Header-Dateien. Zumindest passierte mir das, als ich den gleichen Fehler bekam.

Scannen Sie Ihre Compiler-Ausgabe nach #include <...> search starts here:. Sie können diese Ausgabe auch über die Befehlszeile mit (Quelle) erzwingen :

gcc -Wp,-v -E -

Es sollte ungefähr so ​​aussehen:

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

Beachten Sie, dass die Pfade mit Toolchainsdenen vor denen kommenPlatforms . Wenn in Ihrem Fall die Reihenfolge umgekehrt ist, müssen Sie herausfinden, was in Ihrer Konfiguration dies verursacht. Für mich war es eine explizite Einstellung CPLUS_INCLUDE_PATHin meinem Anmeldeskript.

Beleidigender Code:

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

Dies war Teil meines Versuchs, Xcode 11 zu umgehen und das Installationspaket für die SDK-Header-Dateien nicht mehr bereitzustellen. Nachdem ich diesen Code entfernt hatte, konnte ich ihn erfolgreich einbindencmath in meinen C ++ - Code aufnehmen.

Wenn Sie hierher gekommen sind, um nach Lösungen für dieses Problem zu suchen, benötigen Sie möglicherweise eine andere Lösung. Dies hilft jedoch hoffentlich dabei, die Hauptursache für dieses Problem zu ermitteln, nämlich die Reihenfolge der Suchpfade für Header-Dateien.

Ryan H.
quelle
0

Ich habe festgestellt, dass ich in meinem Projekt eine Datei habe math.h. Nach dem Umbenennen war das Problem verschwunden. Nähte cmathenthalten meine Datei anstelle des Systems.

Gralex
quelle
0

Ich habe gerade diesen Fehler erhalten, als ich versucht habe, gRPC nach dem letzten Upgrade auf 10.15.4 und Xcode 11.4 zu kompilieren, und ich habe angefangen, mir alle angebotenen Lösungen anzusehen (hier und kann nach dem Upgrade auf Catalina 10.15 kein C-Programm auf einem Mac kompilieren ). und versuchte ein paar von ihnen (obwohl nicht versucht, neu zu erstellen/usr/include da dies die Trennung verletzen würde, die Apple zu erstellen versuchte) - nichts schien zu funktionieren.

Ich habe mir dann die tatsächlichen Complier-Aufrufe, die der makeProzess erzeugte, genau angesehen und festgestellt, dass es eine explizite gab

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

Dies führte letztendlich dazu, dass die Includes in der falschen Reihenfolge ausgeführt wurden. Durch Entfernen dieses expliziten Include-Pfads konnte die Kompilierung mit einer Standardinstallation von Catalina, Xcode und den Xcode-Befehlszeilentools erfolgreich durchgeführt werden, wie zu erwarten, ohne weitere Tricks / Compiler-Flags erforderlich.

pahjbo
quelle
Ich bin auch auf dieses Problem gestoßen. Es stellt sich heraus, dass einige pkg-configDateien (z. B. libcurl) von Homebrew diesen Pfad automatisch hinzufügen, selbst wenn Sie Xcode installiert haben. Dies wurde in Homebrew 2.2.13 behoben. Weitere Details unter github.com/Homebrew/brew/issues/5068 ; PR, die dies behebt, befindet sich in github.com/Homebrew/brew/pull/7331 . TL; DR: Update Homebrew
Kkaefer
Ja, es war ein altes Homebrew pkg_config für zlib, das immer noch irgendwie herumlag, was dies für mich verursachte - obwohl ich ein aktuelles Homebrew hatte und momentan sowieso kein zlib installiert hatte
pahjbo
0

Sie können versuchen, das CommandLineTools SDK anstelle des XCode.app SDK zu verwenden.

Ich behebe dieses Problem beim Kompilieren von 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

Außerdem kann eine Neuinstallation von XCode.app und CommandLineTools hilfreich sein.

Lester Lo
quelle
0

Zusammenfassung: In meinem Fall verwendete das Build-Skript eine ältere Version der ios-cmakeToolchain (2.1.2), und durch Aktualisierung auf 3.1.2 wurde das Problem mit cmath / math include behoben.

Anpassen des von @Ryan H. vorgeschlagenen raffinierten Befehls gcc -Wp,-v -E -für meinen Fall (clang, c ++, iOs target)

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

ergibt zwei Catalina, darunter eine jungfräuliche, bei der nur XCode 11.14.1 installiert ist:

 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.

Der richtige Include-Pfad ist also der erste, der nicht ignoriert wird. Alles sollte in Ordnung sein, hat es aber nicht getan. Es scheint, dass das Problem durch einen zusätzlichen include-Befehl verursacht wurde, der von der ios-cmake-Toolchain an den Kompilierungsaufruf angehängt wurde:

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

Der Schuldige war die -Isystem ...Zeile, die dazu führt, dass die #include <math>Zeile in der cmath-Datei die falsche Datei lädt. Nachdem ich viel herumgespielt hatte, um die cmake-Skripte zu reparieren, bemerkte ich die ältere Version von ios-cmake, und die Aktualisierung hatte den "einzigen" Effekt, die unerwünschte -IsystemZeile zu entfernen - alles andere war fast gleich (abgesehen von einigen Compiler-Optionen).

Spikegee
quelle