Catalina C ++: L'utilisation des en-têtes <cmath> génère une erreur: aucun membre nommé «signbit» dans l'espace de noms global
Après la mise à niveau vers Catalina depuis Mojave, configuration: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk dans l'env.
Je ne parviens pas à compiler un programme utilisant <cmath> entête.
J'ai essayé de changer CFLAGS, CCFLAGS, CXXFLAGS pour pointer vers l'emplacement MacOSSDK qui ne change rien
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;
par exemple la macro: isless est présente dans l'espace de noms global et sur mon ordinateur:
➜ 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
➜
Même l'en-tête cmath l'inclut:
➜ cat /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath | grep "math.h"
#include <math.h>
Et ma ligne de commande a l'option -isystem /usr/local/include
Cela devrait fonctionner ...
Je suis curieux: quel compilateur utilisez-vous? Quelle est la valeur de CMAKE_OSX_SYSROOT?
Je suis assez convaincu que c'est le résultat d'un mauvais CMAKE_OSX_SYSROOT. J'ai eu le problème que vous décrivez lorsque vous utilisez python pour clang (où CMake ne gère pas l'appel du compilateur), mais j'ai réussi à recréer l'erreur dans CMake en faisant:
set(CMAKE_OSX_SYSROOT "") # Reset.
J'ai résolu mon problème en suivant les réponses à cette question: Impossible de compiler les packages R avec du code c ++ après la mise à jour vers macOS Catalina .
Pour résumer: Sur Catalina, /usr/include est purgé et protégé par SIP. Par conséquent, tout projet qui s'attend à ce que les en-têtes C y soient trouvés ne pourra pas être compilé. Si je me souviens bien, Apple recommande de déposer des rapports de bogues pour les projets qui attendent des en-têtes C dans /usr/include.
Vous devez pointer le système de génération du code que vous essayez de compiler vers les bons en-têtes:
(1) Assurez-vous que Xcode est à jour. On ne sait pas ce qu'un Xcode obsolète sur Catalina pourrait faire à votre environnement de construction.
(2) Utilisez le -isysroot /sdk/path drapeau du compilateur, où /sdk/path est le résultat de xcrun --show-sdk-path. Je ne sais pas quelle est la meilleure pratique de CMake, mais essayez de faire
set(CMAKE_OSX_SYSROOT /sdk/path)
ou
set(CMAKE_CXX_FLAGS "[...] -isysroot /sdk/path")
Si cela résout le problème, vous voudrez peut-être rechercher une meilleure façon de le faire dans CMake.
Bien sûr, si vous êtes aventureux, vous pouvez également désactiver SIP, comme suggéré dans la réponse à ma question: / usr/include absent sur macOS Catalina (avec Xcode 11)
J'ai le même problème en essayant de cibler iOS (à la fois sur mon MacBook Air et sur le runner GitHub Actions) et voici quelques réflexions supplémentaires sur le problème même si je ne suis pas assez familier avec l'écosystème d'Apple pour suggérer une solution appropriée. La ligne de commande d'origine provenait de CMake dans cpprestsdk, mais une fois que je l'ai réduite à l'essentiel, voici une courte repro.
- Créer un fichier
cmath-bug.cppavec la seule ligne:
#include <cmath>
- Exécuter (les sauts de ligne devant certains arguments sont destinés à faciliter la lecture, supprimez-les)
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
Lorsque je l'exécute, je rencontre le familier de nombreuses personnes confrontées au même problème:
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;
~~^
Les 2 seuls répertoires inclus que je transmets sur ma ligne de commande d'origine existent et sont:
$ 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
...
Mais les éléments intéressants ici sont les répertoires d'inclusion inexistants qu'il rapporte ainsi que les répertoires d'inclusion qu'il finit par rechercher et leur ordre. Je suppose que des répertoires supplémentaires non mentionnés sur la ligne de commande sont insérés par Apple Pilote de Clang basé sur une logique spécifique à Apple.
Vous pouvez voir d'après l'erreur signalée que le <cmath> l'en-tête se trouve à: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath et à la ligne 304, vous pouvez voir:
#include <__config> // Line 304
#include <math.h> // This one ends up causing troubles
#include <__cxx_version>
A en juger par le fait que dans ce même dossier /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ il y a un fichier math.h qui fournit les définitions nécessaires, par exemple:
#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
les auteurs de <cmath> attendaient le math.h de ce même dossier doit être inclus en premier, puis le #include_next <math.h> directive trouve le système spécifique math.h. Ce n'est cependant pas ce qui se passe en réalité.
Si vous regardez les 2 premières entrées dans les répertoires recherchés:
#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
vous voyez que le répertoire d'inclusion spécifique au système finit par être au-dessus du répertoire de bibliothèque standard injecté par Clang, c'est pourquoi le _ spécifique au système math.h est trouvé, pas celui du même dossier que le reste des en-têtes de bibliothèque standard. C'est probablement le cas parce que si j'ajoute explicitement le répertoire include de la bibliothèque standard à ma ligne de commande AVANT les deux autres répertoires -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1 le problème disparaît et je suis en mesure de compiler le fichier. Ce n'est pas ce que le pilote de Clang ou quoi que ce soit d'autre fait ici fait automatiquement: il ajoute ce répertoire de bibliothèque standard via -internal-system (je ne sais pas quelle est la sémantique de cet indicateur interne) et il l'ajoute APRÈS le répertoire système.
Maintenant, si vous regardez la liste des répertoires ignorés, la toute première entrée de cette liste est:
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/usr/include/c++/v1"
dont la queue c++/v1 une partie n'existe pas sur ma machine, ce qui me fait me demander si l'installation du SDK iPhone était censée créer un lien symbolique c++ à l'intérieur de la partie existante du chemin pour pointer vers /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++ répertoire pour que tout fonctionne.
Quoi qu'il en soit, c'est ce que je pense qui se passe et je me demande si quelqu'un sait comment résoudre ce problème correctement?
Je vous remercie!
P.S. Pour le contexte:
$ 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
Il est possible que votre copie de Xcode soit corrompue. Vérifiez avec codesign:
codesign --verify /Applications/Xcode.app
Cela m'est arrivé et le problème était Xcode corrompu. La réinstallation l'a corrigé.
Quelque chose avait modifié ce qui suit:
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 était vide dans tous les endroits ci-dessus.
L'analyse de @ solodon est parfaite. Le problème est probable que le fichier cmath inclut la mauvaise version de math.h basé sur l'ordre de recherche des fichiers d'en-tête. Du moins, c'est ce qui m'arrivait quand je recevais la même erreur.
Analysez la sortie de votre compilateur pour #include <...> search starts here:. Vous pouvez également forcer cette sortie à partir de la ligne de commande avec (source) :
gcc -Wp,-v -E -
Ça devrait ressembler a quelque chose comme ca:
/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)
Notez que les chemins avec Toolchains précèdent ceux avec Platforms. Si dans votre cas, l'ordre est inversé, vous devez déterminer ce qui, dans votre configuration, est à l'origine de cela. Pour moi, c'était un paramètre explicite de CPLUS_INCLUDE_PATH dans mon script de connexion.
Code incriminé:
XCBASE=`xcrun --show-sdk-path`
export CPLUS_INCLUDE_PATH=$XCBASE/usr/include
Cela faisait partie de ma tentative de contourner Xcode 11 en ne fournissant plus le package d'installation pour les fichiers d'en-tête du SDK. Après avoir supprimé ce code, j'ai réussi à inclure cmath dans mon code C++.
Si vous êtes venu ici à la recherche de solutions à ce problème, vous aurez peut-être besoin d'une solution différente, mais nous espérons que cela aidera à faire la lumière sur ce qui semble être la cause première de ce problème, l'ordre du chemin de recherche du fichier d'en-tête.