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

Question

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

I\

Answer 1

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.

Answer 2

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 Can't 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.

Answer 3

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

Answer 4

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.

Answer 5

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)