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 ...
xcode-select -pà l'emplacement de Xcode? Pouvez-vous changer le code enusing std::signbit;, de même pour les autres? Compilez-vous en C ++ 11 ou version ultérieure?xcode-select -pcorrespond oùXCodese trouve.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).Réponses:
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: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 dexcrun --show-sdk-path. Je ne sais pas quelle est la meilleure pratique de CMake, mais essayez de faireou
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)
la source
set(CMAKE_OSX_SYSROOT ...)entreCMakeLists.txt, pas la coquille.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.
cmath-bug.cppavec la seule ligne:Lorsque je l'exécute, je rencontre le familier de nombreuses personnes confrontées au même problème:
Les 2 seuls répertoires d'inclusion que je transmets sur ma ligne de commande d'origine existent et sont:
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: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 fichiermath.hqui fournit les définitions nécessaires, par exemple:les auteurs
<cmath>s'attendaient à cemath.hque le même dossier soit inclus en premier, puis la#include_next <math.h>directive trouve le système spécifiquemath.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:
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:
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 symboliquec++à 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:
la source
Utilisation de la commande:
ma séquence de recherche #include <...>:
La raison de l'erreur #include est décrite ci-dessous:
La solution:
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.
la source
Il est possible que votre copie de Xcode soit corrompue. Vérifiez avec codesign:
Cela m'est arrivé et le problème était Xcode corrompu. La réinstallation l'a corrigé.
Quelque chose avait modifié ce qui suit:
math.hétait vide dans tous les endroits ci-dessus.la source
L'analyse de @ solodon est parfaite. Le problème est probable que le
cmathfichier inclut la mauvaise version demath.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) :Ça devrait ressembler a quelque chose comme ca:
Notez que les chemins avec
Toolchainsviennent avant ceux avecPlatforms. 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 deCPLUS_INCLUDE_PATHdans mon script de connexion.Code incriminé:
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.
la source
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 couturescmathincluent mon fichier au lieu du système.la source
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 explicitequi 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.
la source
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'homebrewVous 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)
De plus, réinstallez XCode.app et CommandLineTools peut vous aider.
la source
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)donne deux Catalina dont un vierge où le seul outil jamais installé est XCode 11.14.1:
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:
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)la source