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)
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.
Create file cmath-bug.cpp with the only line in it:
#include <cmath>
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.
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:
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.
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.
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 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.
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)
Putting together solutions from Ryan H and Solodon solved my problem. Here's how I fixed it (Mac OS 10.15.7):
Make sure you have Xcode.app installed, and have opened it (which will install some additional stuff). We will be using the Xcode compilers to compile our code.
Go into your ~/.zshrc file and add the following lines to make sure the c++ compiler finds the header (.h) files it needs.
#############################
#Give C and C++ compilers directions to the right headers
#which are no longer in /usr/include, as expected.
#We should be using the Xcode.app libraries
XCOD="/Applications/Xcode.app/Contents/Developer"
#Append to the front of the path (reverse order, second line ends up searched first)
export PATH="$XCOD/Toolchains/XcodeDefault.xctoolchain/usr/include:$PATH"
export PATH="$XCOD/Toolchains/XcodeDefault.xctoolchain/usr/bin/:$PATH"
#Append to the end:
export PATH="$PATH:$XCOD/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include"
export PATH="$PATH:$XCOD/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks"
#Tell compiler to use this SDK's compilers to compile C and C++ code
MYSDK="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
export CFLAGS="-isysroot $MYSDK"
export CCFLAGS="-isysroot $MYSDK"
export CXXFLAGS="-isysroot $MYSDK"
export CPPFLAGS="-isysroot $MYSDK"
###########################
Then make these updates take effect by running
source ~/.zshrc
This will make the c++ compiler look for headers (such as math.h) inside Xcode.app in the right order. To verify this has worked, type
gcc -Wp,-v -E -
The result should display the path ending "/XcodeDefault.xctoolchain/usr/bin" before the one ending "/XcodeDefault.xctoolchain/usr/include".
Open the file "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath" and replace the line
#include <math.h>
with
#include </Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h
(This is line 304 on my system). This prevents cmath from trying to use a different math.h header file that exists elsewhere on the system and doesn't have some of the definitions that this cmath file expects it to.
This should be overkill at this point, but to avoid any possible confusion, you can move your other SDKs (such as /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk) somewhere outside your PATH. This prevents any possible conflict between the header files in this SDK and the header files with the same names in the Xcode SDK.
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.
When I try to compile a program with mlton, I get an error.
~/projects/serve-sml $ mlton server.mlb
In file included from /usr/lib/mlton/include/platform.h:13:0,
from /usr/lib/mlton/include/common-main.h:16,
from /usr/lib/mlton/include/amd64-main.h:11,
from /tmp/file86PWQJ.1.c:110:
/usr/lib/mlton/include/cenv.h:137:17: fatal error: gmp.h: No such file or directory
#include "gmp.h"
^
compilation terminated.
call to system failed with exit status 1:
gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include -I/usr/lib/mlton/include -O1 -fno-common -fno-strict-aliasing -fomit-frame-pointer -w -m64 -o /tmp/fileg5D5To.o /tmp/file86PWQJ.1.c
~/projects/serve-sml $
According to this, that means I should install libgmp3-dev. I've run apt-get install libgmp3-dev, and verified that the file /usr/include/x86_64-linux-gnu/gmp.h exists, but am still getting the same error.
Any idea what I'm doing wrong?
Try executing gcc -v -x c -E - in your terminal. This will print out the header file search path that your C compiler is using. I get something like:
#include "..." search starts here:
#include <...> search starts here:
/Users/ml9951/include
.
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
So if I had gmp.h in /usr/include/x86_64-linux-gnu/, then my C compiler would not find it. I would suggest moving your .h file into a directory that is on this search path (like /usr/local/include in my case), or passing in the -I /usr/include/x86_64-linux-gnu/ flag, which would require modifying MLton's build scripts. Chances are you are going to have to do the same thing with libgmp.a when it comes time to link
I have the following program:
#include <stdio.h>
int bob() {
printf("bob\n");
return 0;
}
int main() {
printf("main\n");
return 0;
}
On Linux, I can enable a custom entry point via:
gcc test.c -Wl,-e,bob
When I run the resulting program, I get:
./a.out
bob
On OS X, however, this doesn't work:
clang test.c -Wl,-e,bob
./a.out
main
I've tried everything to get this to work. I think it might be a bug. Here's the output with the -v option:
clang test.c -Wl,-e,bob -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -fdebug-compilation-dir /Users/mfichman/jogo -ferror-limit 19 -fmessage-length 125 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -x c test.c
clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.3.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -e bob -o a.out /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
You can see that clang is correctly passing -e to ld, so maybe this is a problem with Apple's ld. If that's the case, I'd be interested in workaround solutions.
The default entry point overridden by the -e argument is not _main but rather start, which is responsible for setting up and calling _main, then passing the return value of _main to _exit. If you specify your own entry point you'll need to perform these steps yourself. There's currently no way to have this initialization performed for you but use a different main function as use of _main is hard-coded into the tools.
The reason your -e argument is ignored is due to a change in 10.8. Prior to this release the implementation of start was linked into each application via crt1.o. In 10.8 the start processing can be performed by dyld and the LC_MAIN load command specifies the offset to the main function within the program. Changing this offset appears to be what you want, but this is not currently possible as when the LC_MAIN startup method is used ld always uses _main and disregards the -e argument. To specify your own entry point you need to tell ld to use the old method of program startup, which you can do for an application with a deployment target of 10.8 or later by passing -no_new_main to the linker. This is the default behavior for applications with a deployment target earlier than 10.8.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Here is the kind of errors I get, that is definitely not related to my code
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -I/Users/issam/include -o output.o -c project.cpp
In file included from project.cpp:756:
In file included from /Users/issam/include/project.hpp:123:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex.hpp:31:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/regex_traits.hpp:27:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex_traits.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/cpp_regex_traits.hpp:40:
/usr/local/Cellar/boost/1.54.0/include/boost/regex/pending/object_cache.hpp:39:17: error: no type named 'list' in namespace 'std'
typedef std::list<value_type> list_type;
~~~~~^
if I compile a file that only includes:
#include "boost/regex.hpp"
It compiles without any problem and creates the .o file. Here is the verbose output of the compilation
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -o output.o -c newFile.cpp -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name newFile.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -g -coverage-file /Users/issam/folder/output.o -resource-dir /usr/bin/../lib/clang/4.2 -D _TIMER -I /usr/local/Cellar/boost/1.54.0/include -fmodule-cache-path /var/folders/pd/kcfk19hd5mv9vjwsvpqtk_tc0000gq/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/issam/folder -ferror-limit 19 -fmessage-length 168 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o output.o -x c++ newFile.cpp
clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.5.0
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/usr/include/c++/4.0.0"
ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/boost/1.54.0/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/bin/../lib/clang/4.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
boost/regex/pending/object_cache.hpp has the following on line 23:
#include <list>
so for an error such as "error: no type named 'list' in namespace 'std'", it seems likely that your installation of Boost or your compiler toolchain has a problem.
What happens if you try to compile a C++ source file that contains only:
#include "boost/regex.hpp"
I looked it up - the mentioned header file includes <list>, so everything is ok there.
Chances are that you messed up the namespaces by including either boost/regex.hpp or your own project.hpp inside a namespace or by using directives before the #include of either header.
The compiler tells you about an error at the location where it actually sees there was an error, in this case somewhere deep in the guts of the boost headers. Often, when an error is made, you don't notice it immediately, but much later when things look screwed up. It's the same for the compiler this time. It can't say exactly where you messed up, but only how it knows something is wrong.
On a Unix system, where does gcc look for header files?
I spent a little time this morning looking for some system header files, so I thought this would be good information to have here.
`gcc -print-prog-name=cc1plus` -v
This command asks gcc which C++ preprocessor it is using, and then asks that preprocessor where it looks for includes.
You will get a reliable answer for your specific setup.
Likewise, for the C preprocessor:
`gcc -print-prog-name=cpp` -v
In addition, gcc will look in the directories specified after the -I option.
You can create a file that attempts to include a bogus system header.
If you run gcc in verbose mode on such a source, it will list all the system include locations as it looks for the bogus header.
$ echo "#include <bogus.h>" > t.c; gcc -v t.c; rm t.c
[..]
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-apple-darwin9/4.0.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
[..]
t.c:1:32: error: bogus.h: No such file or directory
The CPP Section of the GCC Manual indicates that header files may be located in the following directories. From the Search Path page:
GCC looks in several different places for headers. On a normal Unix system, if you do not instruct it otherwise, it will look for headers requested with #include in:
/usr/local/include
libdir/gcc/target/version/include
/usr/target/include
/usr/include
For C++ programs, it will also look in /usr/include/g++-v3, first.
To get GCC to print out the complete set of directories where it will look for system headers, invoke it like this:
$ LC_ALL=C gcc -v -E -xc - < /dev/null 2>&1 |
LC_ALL=C sed -ne '/starts here/,/End of/p'
which will produce output of the form
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
If you have -I-family options on the command line they will affect what is printed out.
(The sed command is to get rid of all the other junk this invocation prints, and the LC_ALL=C is to ensure that the sed command works -- the "starts here" and "End of search list" phrases are translated IIRC.)
g++ -print-search-dirs
gcc -print-search-dirs
The set of paths where the compiler looks for the header files can be checked by the command:-
cpp -v
If you declare #include "" , the compiler first searches in current directory of source file and if not found, continues to search in the above retrieved directories.
If you declare #include <> , the compiler searches directly in those directories obtained from the above command.
Source:- http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art026
One could view the (additional) include path for a C program from bash by checking out the following:
echo $C_INCLUDE_PATH
If this is empty, it could be modified to add default include locations, by:
export C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/include
These are the directories that gcc looks in by default for the specified header files ( given that the header files are included in chevrons <>);
1. /usr/local/include/ --used for 3rd party header files.
2. /usr/include/ -- used for system header files.
If in case you decide to put your custom header file in a place other than the above mentioned directories, you can include them as follows:
1. using quotes ("./custom_header_files/foo.h") with files path, instead of chevrons in the include statement.
2. using the -I switch when compiling the code.
gcc -I /home/user/custom_headers/ -c foo.c -p foo.o
Basically the -I switch tells the compiler to first look in the directory specified with the -I switch ( before it checks the standard directories).When using the -I switch the header files may be included using chevrons.
My system has gcc9 by default and I have built a gcc12 from source and I think the accepted answer is not correct, that is gcc -print-prog-name=cc1plus -v doesn't give the real include search path.
My build configuration is
Configured with: /home/tian/playground/gcc_build_play/objdir/../gcc-12.1.0/configure --prefix=/home/tian/GCC-12.1.0 --disable-multilib
And no matter where I mv the gcc12 directoy in my machine. It can always include its own c++ header files correctly.
If I type ./gcc -print-prog-name=cc1plus -v, in the original installed directory, it gives:
tian#tian-B250M-Wind:~/GCC-12.1.0/bin$ `./gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include
/usr/local/include
/home/tian/GCC-12.1.0/include
/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed
/usr/include
End of search list.
mv my gcc12 to ~/Desktop/, run again, gives:
tian#tian-B250M-Wind:~/Desktop/GCC-12.1.0/bin$ `./gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0/x86_64-pc-linux-gnu"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include/c++/12.1.0/backward"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/include"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed"
ignoring nonexistent directory "/home/tian/GCC-12.1.0/x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
End of search list.
If that's true, then I compile a program with ./g++, it should use c++ header files in /usr/include or /usr/local/include. But it's not.
Experiment is omitted here. You can try using mv to rename any header file of gcc12 your test program use or add some garbage code to the header file. Then you will see the gcc12 ./g++ is complaining about the gcc12 c++ header file, not my system gcc9's c++ header files in /usr/include or /usr/local/include.
So in both places ./g++ can find its gcc12 c++ headers files correctly.
So I guess gcc and g++ are finding headers in relative directory, relative to /path_to_gcc12/bin/gcc.
Try./g++ -g -Wall --verbose -o test test.cpp gives the real include path:
tian#tian-B250M-Wind:~/Desktop/GCC-12.1.0/bin$ ./g++ -g -Wall --verbose -o test test.cpp
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/home/tian/Desktop/GCC-12.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/tian/playground/gcc_build_play/objdir/../gcc-12.1.0/configure --prefix=/home/tian/GCC-12.1.0 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)
COLLECT_GCC_OPTIONS='-g' '-Wall' '-v' '-o' 'test' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/tian/Desktop/GCC-12.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/ -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -Wall -version -o /tmp/ccrg0qhG.s
GNU C++17 (GCC) version 12.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed"
ignoring nonexistent directory "/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed
/usr/local/include
/home/tian/Desktop/GCC-12.1.0/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
So I think my guess is correct.