Catalina C++: Using <cmath> headers yield error: no member named 'signbit' in the global namespace

After upgrading to Catalina from Mojave, Setuping: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk in the env.

I'm unable to compile a program that use <cmath> header.

I tried changing CFLAGS, CCFLAGS, CXXFLAGS to point to the MacOSSDK Location that change nothing

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;

for example the macro: isless is present in the global namespace and on my computer:

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

Even the cmath header include it:

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

And my command line have the option -isystem /usr/local/include

This should work...

I'm curious: What compiler are you using? What's the value of CMAKE_OSX_SYSROOT?

I'm fairly convinced this is the result of a wrong CMAKE_OSX_SYSROOT. I had the problem you're describing when using python bindings for clang (where CMake doesn't manage the compiler call), but I managed to recreate the error in CMake by doing:

set(CMAKE_OSX_SYSROOT "")  # Reset.

I solved my problem by following the answers to this question: Cannot compile R packages with c++ code after updating to macOS Catalina.

To summarise: On Catalina, /usr/include is purged and protected by SIP. Thus, any project that expects the C headers to be found there will fail to compile. If I remember correctly, Apple recommends to file bug reports to projects that expect C headers in /usr/include.

You must point the build system of the code you're trying to compile to the right headers:

(1) Make sure Xcode is up to date. There's no telling what an outdated Xcode on Catalina might do to your build environment.

(2) Use the -isysroot /sdk/path compiler flag, where /sdk/path is the result of xcrun --show-sdk-path. I'm not sure what CMake's best practice is, but try doing

set(CMAKE_OSX_SYSROOT /sdk/path)

or

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

If that solves the problem, you may want to look for a better way to do this in CMake.

Of course, if you're adventurous, you could also disable SIP, as suggested in the answer to my question: /usr/include missing on macOS Catalina (with Xcode 11)

Using the command:

gcc -Wp,-v -E -

my #include <...> search sequence:

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

The reason of #include error is described below:

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

The fix:

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

I have followed the #2 option and build is successful now!

And thanks to solodon for the detailed answer. I followed the answer to fix the issue.

I am having the same problem while trying to target iOS (both on my MacBook Air and on GitHub Actions runner) and here are a few more thoughts on the problem even though I'm not familiar enough with Apple's ecosystem to suggest a proper solution. The original command line was coming from CMake in cpprestsdk, but once I boiled it down to essentials, here is a short repro.

1. Create file cmath-bug.cpp with the only line in it:

    #include <cmath>

2. Run (newlines in front of some arguments are for reading convenience, remove them)

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

When I run it, i get the familiar to many facing the same issue:

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

The only 2 include directories I pass on my original command line exist and are:

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

But the interesting bits here are the non-existing include directories it reports as well as the include directories it ends up searching eventually and their order. My guess is that additional directories not mentioned on the command line are inserted by Apple Clang's driver based on some Apple-specific logic.

You can see from the reported error that the <cmath> header is found at: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath and at line 304 of it you can see:

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

Judging from the fact that in that same folder /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ there is a file math.h that provides the necessary definitions, e.g.:

#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

the authors of <cmath> were expecting the math.h from that same folder be included first and then the #include_next <math.h> directive find the system-specific math.h. That is not what's happening in reality however.

If you look at the first 2 entries in searched directories:

#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

you see that system-specific include directory ends up being above the Clang-injected standard library directory, which is why the system-specific math.h is being found, not the one in the same folder as the rest of the standard library headers. This is likely the case because if I explicitly add the standard library include directory to my command line BEFORE the other two directories -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1 the problem goes away and I am able to compile the file. That's not what Clang's driver or whatever else is involved here does automatically: it adds that standard library directory via -internal-system (not sure what's the semantics of that internal flag) and it adds it AFTER the system directory.

Now if you look at the list of ignored directories, the very first entry in that list is:

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

of which the trailing c++/v1 part does not exist on my machine, making me wonder whether the iPhone SDK installation was supposed to create a symbolic link c++ inside the existing part of the path to point to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++ directory to make the whole thing work.

Anyways, this what I think is happening and I wonder if anyone knows how to properly fix this?

Thank you!

P.S. For the context:

$ 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

You may try to use the CommandLineTools SDK rather than the XCode.app SDK.

I fix this problem when I compiling 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

Also, reinstall XCode.app and CommandLineTools may help.

It is possible your copy of Xcode is corrupted. Check with codesign:

codesign --verify /Applications/Xcode.app

This happened to me, and the problem was corrupted Xcode. Reinstalling fixed it.

Something had modified the following:

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 was empty in all the above places.

I found that inside my project I have file math.h. After rename it the problem was disappear. Seams cmath include my file instead of system.

I have just got this error when trying to compile gRPC after recently upgrading to 10.15.4 and Xcode 11.4 and I started to look at all the solutions offered (here and https://stackoverflow.com/questions/58278260/cant-compile-a-c-program-on-a-mac-after-upgrading-to-catalina-10-15), and tried a few of them (though not trying to recreate /usr/include as that would violate the separation that Apple were trying to create) - nothing seemed to work.

I then looked closely at the actual complier invocations that the make process was producing and noticed that there was an explicit

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

that was ultimately causing the includes to happen in the wrong order - removing this explicit include path allowed the compilation to succeed with a default install of catalina, Xcode and the Xcode command-line tools, as you would expect, no other tricks/compiler flags needed.

Reinstalling Xcode, command tools and homebrew, and

sudo rm -rf /usr/local/include

fixed this issue for me.

I finally figured out why this was affecting only some people. When Catalina came out, they stopped shipping the command line tools package with the /usr headers. A common workaround was to use CPATH to point to the system headers in your bashrc like this:

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

However this appears to mess up the C++ include path ordering for cmath and math.h (as found in the other answers). The good news is that it seems that current homebrew builds of clang and gcc don't need CPATH set anymore to find the system headers. So you can just remove the CPATH override and be done with it.

@solodon's analysis is spot on. The issue is likely that the cmath file is including the wrong version of math.h based on the search order of the header files. At least, this is what was happening to me when I was getting the same error.

Scan your compiler output for #include <...> search starts here:. You can also force this output from the command line with (source):

gcc -Wp,-v -E -

It should look something like this:

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

Notice that the paths with Toolchains come before those with Platforms. If in your case the order is reversed, you need to figure out what in your configuration is causing this. For me, it was an explicit setting of CPLUS_INCLUDE_PATH in my login script.

Offending code:

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

This was part of my attempt to work around Xcode 11 no longer providing the installation package for the SDK header files. After removing this code, I was able to successfully include cmath in my C++ code.

If you came here looking for solutions to this issue, you may require a different solution but hopefully this helps to shed light on what seems to be the root cause of this issue, header file search path order.

Deleting MacOSX10.15.sdk works.

In my case, it happened when I cmake llvm project and build the cmaked project in Xcode. This error was detected when compiling LibEdit.
I had successfully compiled this project on my MBP, but failed on my iMac. Both of them are the same macOS 11.3.1, Xcode 12.5, Command Line Tools 12.5, The same goes for other configurations.

So I compared the cmake log, and find the different: On MBP, log For LibEdit was:

-- Found LibEdit: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include (found version ".") 

On iMac, log For LibEdit was:

-- Found LibEdit: /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include (found version ".")

This is what caused the build error.

The CommandLineTools directory files are Exactly the same:

MacOSX11.1.sdk,
MacOSX11.3.sdk,
MacOSX10.15.sdk,
MacOSX.sdk link to MacOSX11.3.sdk
MacOSX11.sdk link to MacOSX11.3.sdk

and Both Command Line Tools in Xcode - Preferences - Locations are set to Xcode12.5(12E262)

and I reinstalled Xcode and Command Line Tools on iMac. But no use.

the cmake command has specifies -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk". Still no use.

I don't know where else to set this. Finally, I deleted the MacOSX10.15.sdk, and it worked.

@mkl 's solution helps to fix the similar issue on my side. Thanks.

Issue and solution on my side

I got the same issue to compile a project on basis of PCL. The solution is to set CommandLineTools SDK CMAKE_OSX_SYSROOT.

I tried @mkl's solution to do it in CMakeLists.txt, it doesn't work. So that I can only set it by cmake .. -DCMAKE_OSX_SYSROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk"

Another thing to mention: there are two versions of command line SDKs in my MacOS:

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

xcrun --show-sdk-path gives out the default one, but actually only MacOSX10.14.sdk works on my side.

Discussion of the similar issue in PCL's repo: https://github.com/PointCloudLibrary/pcl/issues/2601#issuecomment-621889211

Difference between SDKs

I don't know much about cmake and SDKs in c++. The difference I noticed in cmake building log from different SDKs as following:

/Library/Developer/CommandLineTools/SDKs/MacOSX:

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

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

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

On default:

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

Seems like the issue happens on SDK choice for Opengl.

How to do it in CMakeLists.txt?

Appreciated it if anyone could advice.

Summary: in my case, the build script was using an older version of ios-cmake toolchain (2.1.2), and updating it to 3.1.2 fixed the cmath/math include issue.

Adapting the nifty command proposed by @Ryan H. gcc -Wp,-v -E - for my case (clang, c++, iOs target)

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

yields on two Catalina including a virgin one where only tool ever installed is 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.

So the correct include path is the first non-ignored one, everything should work OK, but it didn't. It appears the issue came from an additional include command appended to the compilation call by the ios-cmake toolchain:

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

The culprit was the -Isystem ... line, which will cause the #include <math> line in the cmath file to end up loading the wrong file. After much fiddling around trying to fix the cmake scripts, I noticed the older version of ios-cmake, and updating it had the 'only' effect of removing the unwanted -Isystem line - everything else was almost the same (apart from a few compiler option)

The compiler tries to find math.h and usually it will find it under /usr/local/include first and then get a wrong one.

An easy way to fix it is to rename it using: mv /usr/local/include/math.h /usr/local/include/math_old.h. Then the compiler would try the following include directories.