Catalina C ++: L'utilisation des en-têtes <cmath> génère une erreur: aucun membre nommé «signbit» dans l'espace de noms global

16

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 l'en- <cmath>tê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: islessest 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 ...

Roman Sztergbaum
la source
Correspond xcode-select -pà l'emplacement de Xcode? Pouvez-vous changer le code en using std::signbit;, de même pour les autres? Compilez-vous en C ++ 11 ou version ultérieure?
Eljay
Compiler en C ++ 11. Je ne peux pas changer le code, c'est une dépendance externe! oui xcode-select -pcorrespond où XCodese trouve.
Roman Sztergbaum
Ce n'est pas bon. Le code essaie de faire using ::signbit;et le symbole n'est pas dans l'espace de noms global, il est dans l' std::espace de noms. Je présume de même avec les autres (je ne les ai pas pourchassés).
Eljay

Réponses:

7

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 tort CMAKE_OSX_SYSROOT. J'ai eu le problème que vous décrivez lorsque vous utilisez des liaisons 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 le code c ++ après la mise à jour vers macOS Catalina .

Pour résumer: Sur Catalina, /usr/includeest 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 aux rapports de bogues de fichiers à des projets qui attendent les 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 l' -isysroot /sdk/pathindicateur du compilateur, où /sdk/pathest 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 missing sur macOS Catalina (avec Xcode 11)

mkl
la source
1
set(CMAKE_OSX_SYSROOT ...)entre CMakeLists.txt, pas la coquille.
mkl
6

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.

  1. Créez un fichier cmath-bug.cppavec la seule ligne:
    #include <cmath>
  1. Exécuter (les sauts de ligne devant certains arguments sont pour 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 d'inclusion 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 le pilote d'Apple Clang sur la base d'une logique spécifique à Apple.

Vous pouvez voir d'après l'erreur signalée que l'en- <cmath>tête se trouve à: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmathet à la ligne 304 de celui-ci, 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 existe un fichier math.hqui 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 <cmath>s'attendaient à ce math.hque le même dossier soit inclus en premier, puis la #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 répertoire spécifique au système math.hest trouvé, pas celui dans le même dossier que le reste des en-têtes de bibliothèque standard. C'est probablement le cas car 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++/v1le problème disparaît et je suis en mesure de compiler le fichier. Ce n'est pas ce que le pilote de Clang ou tout ce qui est impliqué 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 c++/v1partie arrière n'existe pas sur ma machine, ce qui me fait me demander si l'installation iPhone SDK était censée créer un lien symbolique c++à l'intérieur de la partie existante du chemin pour pointer vers le /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 correctement cela?

Je vous remercie!

PS 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
solodon
la source
2

Utilisation de la commande:

gcc -Wp,-v -E -

ma séquence de recherche #include <...>:

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

La raison de l'erreur #include est décrite ci-dessous:

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

La solution:

    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

J'ai suivi l'option # 2 et la construction est réussie maintenant!

Et merci à solodon pour la réponse détaillée. J'ai suivi la réponse pour résoudre le problème.

Niloy Datta
la source
Salut Niloy Datta! Je vous suggère de modifier cette réponse en supprimant la question de cette réponse et d'inclure uniquement les réponses. Si vous avez une question, posez-la séparément de la bonne manière, les questions devraient être posées dans cette communauté.
Tiago Martins Peres 李大仁
1
@TiagoMartinsPeres 李大仁, l'a supprimé. Merci.
Niloy Datta
Merci mec, ça a marché pour moi. Connaissez-vous un moyen plus propre de résoudre ce problème?
Victor Sanchez
1

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.

Rob Napier
la source
1

L'analyse de @ solodon est parfaite. Le problème est probable que le cmathfichier inclut la mauvaise version de math.hbasé 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 #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 Toolchainsviennent avant 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_PATHdans 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 à l'inclure avec succès cmathdans 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.

Ryan H.
la source
0

J'ai trouvé qu'à l'intérieur de mon projet, j'avais un fichier math.h. Après l'avoir renommé, le problème a disparu. Les coutures cmathincluent mon fichier au lieu du système.

Gralex
la source
0

Je viens de recevoir cette erreur en essayant de compiler gRPC après avoir récemment mis à niveau vers 10.15.4 et Xcode 11.4 et j'ai commencé à regarder toutes les solutions proposées (ici et Impossible de compiler un programme C sur un Mac après la mise à niveau vers Catalina 10.15 ) , et j'en ai essayé quelques-uns (sans essayer de recréer /usr/includecar cela violerait la séparation qu'Apple essayait de créer) - rien ne semblait fonctionner.

J'ai ensuite examiné de près les appels de complices réels que le makeprocessus produisait et j'ai remarqué qu'il y avait une explicite

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

qui provoquait finalement les inclusions dans le mauvais ordre - la suppression de ce chemin d'inclusion explicite a permis à la compilation de réussir avec une installation par défaut de catalina, Xcode et les outils de ligne de commande Xcode, comme vous vous en doutez, sans autres astuces / indicateurs de compilateur nécessaire.

pahjbo
la source
J'ai également rencontré ce problème. Il s'avère que certains pkg-configfichiers (par exemple libcurl) de Homebrew ajoutent automatiquement ce chemin, même si Xcode est installé. Cela a été corrigé dans Homebrew 2.2.13. Plus de détails sur github.com/Homebrew/brew/issues/5068 ; Le PR qui résout ce problème se trouve sur github.com/Homebrew/brew/pull/7331 . TL; DR: Mise à jour de l'homebrew
kkaefer
Oui, c'était un vieil homebrew pkg_config pour zlib qui traînait toujours, qui me causait cela - malgré un homebrew à jour et sans avoir actuellement installé zlib de toute façon
pahjbo
0

Vous pouvez essayer d'utiliser le SDK CommandLineTools plutôt que le SDK XCode.app.

Je résout ce problème lors de la compilation de 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

De plus, réinstallez XCode.app et CommandLineTools peut vous aider.

Lester Lo
la source
0

Résumé: dans mon cas, le script de construction utilisait une ancienne version de la ios-cmakechaîne d' outils (2.1.2), et sa mise à jour vers 3.1.2 a résolu le problème d'inclusion de cmath / math.

Adapter la commande astucieuse proposée par @Ryan H. gcc -Wp,-v -E -pour mon cas (clang, c ++, cible iOs)

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

donne deux Catalina dont un vierge où le seul outil jamais installé est 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.

Ainsi, le chemin d'inclusion correct est le premier non ignoré, tout devrait fonctionner correctement, mais ce n'est pas le cas. Il semble que le problème provienne d'une commande d'inclusion supplémentaire ajoutée à l'appel de compilation par la chaîne d'outils 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
...

Le coupable était la -Isystem ...ligne, ce qui entraînera le #include <math>chargement du mauvais fichier dans la ligne du fichier cmath. Après avoir beaucoup essayé de corriger les scripts cmake, j'ai remarqué l'ancienne version d'ios-cmake et sa mise à jour avait le `` seul '' effet de supprimer la -Isystemligne indésirable - tout le reste était presque le même (à part quelques options de compilation)

Spikegee
la source