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 lors de l'utilisation de 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_CXX_FLAGS "[...] -isysroot /sdk/path")

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. Ainsi, tout projet qui s'attend à ce que les en-têtes C y soient trouvés échouera à se compiler. Si je me souviens bien, Apple recommande de déposer des rapports de bogue pour les projets qui attendent des en-têtes C dans /usr/include .

Vous devez pointer le système de construction 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/path du -isysroot /sdk/path , 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_OSX_SYSROOT "")  # Reset.

Si cela résout le problème, vous souhaiterez peut-être rechercher un meilleur moyen 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)

J'ai le même problème en essayant de cibler iOS (à la fois sur mon MacBook Air et sur GitHub Actions runner) et voici quelques réflexions supplémentaires sur le problème même si je ne connais pas suffisamment l'écosystème d'Apple pour suggérer une solution appropriée. La ligne de commande originale provenait de CMake dans cpprestsdk, mais une fois que je l'ai résumée à l'essentiel, voici une courte repro.

1. Créez le fichier cmath-bug.cpp avec la seule ligne:

$ 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

2. Exécuter (les retours à la ligne devant certains arguments sont pour faciliter la lecture, supprimez-les)

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

Lorsque je l'exécute, je connais beaucoup de personnes confrontées au même problème:

#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

Les 2 seuls répertoires d'inclusion que je passe sur ma ligne de commande d'origine existent et sont:

#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

Mais les éléments intéressants ici sont les répertoires d'inclusion non existants qu'il signale ainsi que les répertoires d'inclusion qu'il finit par rechercher et leur ordre. Je suppose que les répertoires supplémentaires non mentionnés sur la ligne de commande sont insérés par le pilote d'Apple Clang en fonction d'une logique spécifique à Apple.

Vous pouvez voir à partir de l'erreur signalée que l'en-tête <cmath> se trouve à: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath et à la ligne 304 de celui-ci, vous peut voir:

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

À 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:

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

les auteurs de <cmath> s'attendaient à ce que le math.h de ce même dossier soit inclus en premier, puis la directive #include_next <math.h> trouve le math.h spécifique au système. 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:

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

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 math.h spécifique au système est trouvé, et non 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 d'inclusion 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 tout ce qui est impliqué ici fait automatiquement: il ajoute ce répertoire de bibliothèque standard via -internal-system (pas sûr de 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:

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

dont la partie c++/v1 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++ 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 ce problème?

Merci!

PS Pour le contexte:

    #include <cmath>

Il est possible que votre copie de Xcode soit corrompue. Vérifiez avec le code:

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

Cela m'est arrivé et le problème était un Xcode corrompu. La réinstallation l'a corrigé.

Quelque chose avait modifié ce qui suit:

codesign --verify /Applications/Xcode.app

math.h était vide dans tous les endroits ci-dessus.

L'analyse de @ solodon est parfaite. Le problème est probablement que le fichier cmath la mauvaise version de math.h fonction de l'ordre de recherche des fichiers d'en-tête. Du moins, c'est ce qui m'arrivait lorsque j'obtenais la même erreur.

Analysez la sortie de votre compilateur pour la recherche #include <...> search starts here: Vous pouvez également forcer cette sortie depuis la ligne de commande avec (source) :

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

Ç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 en est la cause. Pour moi, c'était un paramètre explicite de CPLUS_INCLUDE_PATH dans mon script de connexion.

Code incriminé:

gcc -Wp,-v -E -

Cela faisait partie de ma tentative de contourner Xcode 11 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 j'espère 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.

J'ai trouvé que dans mon projet, j'ai le fichier math.h Après l'avoir renommé, le problème a disparu. Les coutures cmath incluent mon fichier au lieu du système.

Je viens de recevoir cette erreur en essayant de compiler gRPC après une récente mise à 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 en a essayé quelques-uns (sans essayer de recréer /usr/include car cela violerait la séparation qu'Apple essayait de créer) - rien ne semblait fonctionner.

J'ai alors regardé attentivement les invocations de complier réelles que la make processus a été la production et remarqué qu'il y avait un explicite

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

cela 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, pas d'autres astuces / indicateurs de compilateur nécessaire.

En utilisant la commande:

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

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

gcc -Wp,-v -E -

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

• #include<cmath> réside dans /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
• Il inclut <math.h> .
• Il recherche le /usr/local/include car il s'agit du premier répertoire à rechercher. Il y a un math.h dans le répertoire /usr/local/include/c++/9.3.0/
• Il essaie de l'utiliser.
• Mais l'attente était d'utiliser le math.h du même répertoire /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
• Le math.h de /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 inclut math.h de /usr/local/include utilisant #include_next<math.h>
• Comme le mauvais math.h est inclus / lié à /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath , l'erreur de compilation se produit

Le correctif:

1. Si nous pouvons modifier l'ordre de recherche de #include<...> pour rechercher /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 dans un premier temps, cela peut être corrigé.

2. Utilisation de #include</Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h> au lieu de <math.h> dans /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath

J'ai suivi l'option n ° 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.

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

Je corrige ce problème lorsque je compile 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

En outre, réinstallez XCode.app et CommandLineTools peut vous aider.

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

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

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

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

Le chemin d'inclusion correct est donc 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:

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

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

La solution de @mkl aide à résoudre le problème similaire de mon côté. Merci.

Problème et solution de mon côté

J'ai eu le même problème pour compiler un projet sur la base de PCL . La solution consiste à définir le SDK CommandLineTools CMAKE_OSX_SYSROOT.

J'ai essayé la solution de @ mkl pour le faire dans CMakeLists.txt, cela ne fonctionne pas. Pour que je ne puisse le définir que par cmake .. -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk"

Autre chose à mentionner: il existe deux versions de SDK en ligne de commande dans mon MacOS:

-- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework

xcrun --show-sdk-path donne la valeur par défaut, mais en fait seul MacOSX10.14.sdk fonctionne de mon côté.

Discussion du problème similaire dans le repo de PCL: https://github.com/PointCloudLibrary/pcl/issues/2601#issuecomment-621889211

Différence entre les SDK

Je ne sais pas grand-chose sur cmake et les SDK en c ++. La différence que j'ai remarquée dans le journal de construction cmake à partir de différents SDK comme suit:

/Library/Developer/CommandLineTools/SDKs/MacOSX :

-- Found OpenGL: /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework

/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk

-- Found OpenGL: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework

Par défaut:

~ » /Library/Developer/CommandLineTools/SDKs/MacOSX
/Library/Developer/CommandLineTools/SDKs/MacOSX
MacOSX.sdk/       MacOSX10.14.sdk@

On dirait que le problème se produit lors du choix du SDK pour Opengl.

Comment le faire dans CMakeLists.txt?

J'ai apprécié si quelqu'un pouvait donner des conseils.

Réinstaller Xcode, les outils de commande et les homebrews, et

sudo rm -rf /usr/local/include

corrigé ce problème pour moi.