Catalina C++: Verwenden Header ergeben Fehler: kein Mitglied mit dem Namen „signbit“ im globalen Namensraum

Lesezeit: 16 Minuten

Catalina C Verwenden Header ergeben Fehler kein Mitglied mit dem
Roman Sztergbaum

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

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

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 ist im globalen Namensraum 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 es:

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

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

Das sollte funktionieren…

  • Tut xcode-select -p übereinstimmen, wo sich Xcode befindet? Kannst du den Code ändern auf using std::signbit;, ebenso für die anderen? Kompilieren Sie als C++11 oder höher?

    – Eljay

    30. Oktober 2019 um 15:43 Uhr


  • Kompilieren als C++ 11. Ich kann den Code nicht ändern, es handelt sich um eine externe Abhängigkeit! Jawohl xcode-select -p übereinstimmen wo XCode befindet sich.

    – Roman Sztergbaum

    30. Oktober 2019 um 15:51 Uhr


  • Das ist nicht gut. Der Code versucht zu tun using ::signbit; und das Symbol befindet sich nicht im globalen Namensraum, sondern darin std:: Namensraum. Ich vermute das gleiche mit den anderen (ich habe sie nicht verfolgt).

    – Eljay

    30. Oktober 2019 um 16:38 Uhr

Catalina C Verwenden Header ergeben Fehler kein Mitglied mit dem
mkl

Mich interessiert: Welchen Compiler verwendest du? Was ist der Wert von CMAKE_OSX_SYSROOT?

Ich bin ziemlich davon überzeugt, dass dies das Ergebnis eines Fehlers 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 wiederherzustellen, indem Sie Folgendes tun:

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/include wird 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 zu Projekten einzureichen, die C-Header erwarten /usr/include.

Sie müssen das Build-System des Codes, den Sie zu kompilieren versuchen, 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 mit Ihrer Build-Umgebung machen könnte.

(2) Verwenden Sie die -isysroot /sdk/path Compiler-Flag, wo /sdk/path ist das Ergebnis von xcrun --show-sdk-path. Ich bin mir nicht sicher, was die bewährte Methode von CMake ist, aber versuchen Sie es

set(CMAKE_OSX_SYSROOT /sdk/path)

oder

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

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

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

  • set(CMAKE_OSX_SYSROOT ...) gehört in CMakeLists.txtnicht die Schale.

    – mkl

    21. März 2020 um 17:17 Uhr

Ich habe das gleiche Problem beim Versuch, iOS anzusprechen (sowohl auf meinem MacBook Air als auch auf GitHub Actions Runner), und hier sind ein paar weitere Gedanken zu dem Problem, obwohl ich mit Apples Ökosystem nicht vertraut genug bin, um eine geeignete Lösung vorzuschlagen. Die ursprüngliche Befehlszeile kam von CMake in cpprestsdk, aber nachdem ich es auf das Wesentliche reduziert habe, ist hier eine kurze Wiederholung.

  1. Erstelle Datei cmath-bug.cpp mit der einzigen Zeile darin:
    #include <cmath>
  1. Ausführen (Zeilenumbrüche vor einigen Argumenten dienen der Lesefreundlichkeit, 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 ausführe, erhalte ich das Vertraute vieler mit dem gleichen Problem:

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 auf meiner ursprünglichen Befehlszeile übergebe, existieren 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
 ...

Aber die interessanten Teile hier sind die nicht existierenden Include-Verzeichnisse, die es meldet, sowie die Include-Verzeichnisse, die es letztendlich durchsucht, und ihre Reihenfolge. Meine Vermutung ist, dass zusätzliche Verzeichnisse, die nicht in der Befehlszeile erwähnt werden, vom Apple Clang-Treiber basierend auf einer Apple-spezifischen Logik eingefügt werden.

Sie können aus dem gemeldeten Fehler ersehen, dass die <cmath> Kopfzeile ist zu finden unter: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath und 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 in demselben Ordner /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ da ist eine datei math.h die die notwendigen Definitionen bereitstellt, 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 die math.h aus demselben Ordner zuerst aufgenommen werden und dann die #include_next <math.h> Direktive finden Sie die systemspezifische math.h. Das ist jedoch nicht das, was in der Realität passiert.

Wenn Sie sich die ersten 2 Einträge in durchsuchten 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 Clang-injizierten Standardbibliotheksverzeichnis liegt, weshalb das systemspezifische math.h gefunden wird, nicht diejenige im selben Ordner wie die übrigen Header der Standardbibliothek. Dies ist wahrscheinlich der Fall, weil, wenn ich das Verzeichnis der Standardbibliothek explizit vor den anderen beiden Verzeichnissen zu meiner Befehlszeile hinzufüge -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1 Das Problem verschwindet und ich kann die Datei kompilieren. Das macht der Clang-Treiber oder was auch immer hier sonst noch involviert ist, nicht automatisch: Er fügt das Standard-Bibliotheksverzeichnis über hinzu -internal-system (nicht sicher, was die Semantik dieses internen Flags ist) und es wird NACH dem Systemverzeichnis hinzugefügt.

Wenn Sie sich nun die Liste der ignorierten Verzeichnisse ansehen, ist 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"

davon das nachlaufende c++/v1 part auf meinem Computer nicht existiert, weshalb ich mich frage, ob die iPhone SDK-Installation einen symbolischen Link erstellen sollte c++ innerhalb des vorhandenen Teils des Pfads, auf den gezeigt werden soll /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++ Verzeichnis, damit das Ganze funktioniert.

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

Danke!

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

  • Vielen Dank für Ihre Detailerklärung. Aber leider scheint keine Lösung für meine Maschine zu funktionieren. Ich bin dabei, mich für die letzte Option zu entscheiden, Catalina neu zu installieren. Verdammtes Apple, warum machen sie die Dinge so schwierig?

    – Jäger

    9. Juni 2020 um 15:12 Uhr

  • Ich habe diese Anweisungen von oben befolgt, um einen Pfad zu math.h fest zu codieren. Das hat eine Weile gut funktioniert, aber ich vermute, dass eine neuere Version von Xcode dies kaputt gemacht hat und ich Kompilierungsfehler mit math.h erhalten habe. Damit nicht mach das 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!!!

    – JerryN

    18. Juni 2020 um 19:27 Uhr


  • Auf meiner Seite wurde das Problem durch Entfernen des Verzeichnisses behoben /Library/Developer/CommandLineTools. Ich habe Swift für Android auf macOS Catalina entwickelt.

    – Vlad

    16. Oktober 2020 um 14:35 Uhr

1646254813 32 Catalina C Verwenden Header ergeben Fehler kein Mitglied mit dem
Niloy Datta

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 #include-Fehler wird im Folgenden beschrieben:

  • #include<cmath> wohnt in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
  • Es enthält <math.h>.
  • Es sucht /usr/local/include Verzeichnis, da dies das erste Verzeichnis ist, das durchsucht wird. Da ist ein math.h in /usr/local/include/c++/9.3.0/ Verzeichnis
  • Es versucht, dies zu nutzen.
  • Aber die Erwartung war, die zu verwenden math.h des gleichen Verzeichnisses /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
  • Die math.h von /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 enthalten math.h von /usr/local/include verwenden #include_next<math.h>
  • Als falsch math.h ist enthalten/verknüpft mit /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmathtritt der Kompilierungsfehler auf

Die Reparatur:

  1. Wenn wir die Suchreihenfolge von ändern können #include<...> suchen /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 zunächst kann es behoben werden.

  2. Verwenden #include</Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h> anstatt <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 bin der Antwort gefolgt, um das Problem zu beheben.

  • Hallo Niloy Datta! Ich schlage vor, dass Sie diese Antwort bearbeiten, indem Sie die Frage aus dieser Antwort entfernen und nur die Antworten angeben. Wenn Sie eine Frage haben, stellen Sie diese separat auf die richtige Art und Weise, wie Fragen in dieser Community gestellt werden sollten.

    – Tiago Martins Peres

    30. April 2020 um 8:56 Uhr

  • @TiagoMartinsPeres李大仁, entfernt. Danke.

    – Niloy Datta

    2. Mai 2020 um 4:17 Uhr

  • Danke Mann, bei mir hat es funktioniert. Kennen Sie einen saubereren Weg, um mit diesem Problem umzugehen?

    – Hector Esteban

    5. Mai 2020 um 17:30 Uhr

  • @VictorSanchez, versuche immer noch, es herauszufinden. Werde benachrichtigen sobald ich es habe.

    – Niloy Datta

    7. Mai 2020 um 4:02 Uhr

  • Das Problem ist, dass ich bei der Verwendung von PCL die Änderung vornehmen muss, aber manchmal, wenn ich nur cmath importiere, muss ich es rückgängig machen

    – Hector Esteban

    13. Mai 2020 um 22:37 Uhr

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

Ich behebe dieses Problem, wenn ich PointCloudLibrary (PCL) kompiliere

#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

Auch eine Neuinstallation von XCode.app und CommandLineTools kann hilfreich sein.

Es ist möglich, dass Ihre Kopie von Xcode beschädigt ist. Überprüfen Sie mit Codesign:

codesign --verify /Applications/Xcode.app

Das ist mir passiert, und das Problem war beschädigter Xcode. Neuinstallation hat es 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 Orten leer.

1646254813 423 Catalina C Verwenden Header ergeben Fehler kein Mitglied mit dem
Gralex

Ich habe festgestellt, dass ich in meinem Projekt eine Datei habe math.h. Nach dem Umbenennen war das Problem verschwunden. Nähte cmath schließen Sie meine Datei anstelle von System ein.

1646254814 860 Catalina C Verwenden Header ergeben Fehler kein Mitglied mit dem
Aaron Holtzmann

Ich habe endlich herausgefunden, warum dies nur einige Leute betraf. Als Catalina herauskam, stellten sie die Auslieferung des Befehlszeilen-Tools-Pakets mit den /usr-Headern ein. Eine gängige Problemumgehung bestand darin, CPATH zu verwenden, um wie folgt auf die Systemheader in Ihrem bashrc zu verweisen:

export CPATH=`xcrun --show-sdk-path`/usr/include

Dies scheint jedoch die C++-Pfadreihenfolge für cmath und math.h durcheinander zu bringen (wie in den anderen Antworten zu finden). Die gute Nachricht ist, dass es scheint, dass aktuelle Homebrew-Builds von clang und gcc kein CPATH-Set mehr benötigen, um die System-Header zu finden. Sie können also einfach die CPATH-Überschreibung entfernen und fertig.

916090cookie-checkCatalina C++: Verwenden Header ergeben Fehler: kein Mitglied mit dem Namen „signbit“ im globalen Namensraum

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy