Is there a way to tell gcc/g++/clang where to look for headers that are included via angle brackets ("<", ">")?
I don't use the angle bracket convention for non-system files, but the problem is that when I try using the headers from some packages I download, I get errors for all of the included files.
For example, say I want to include headers from a module called Foo that I download:
/foo-v1.0/include/DependencyA.hpp:
#ifndef DEP_A_HPP
#define DEP_A_HPP
class DependencyA
{
...
};
#endif
/foo-v1.0/include/Api.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include <Foo/DependencyA.hpp>
void doSomething(DependencyA* da);
#endif
Then, in my own code:
/mycode.cpp:
#include "/foo-v1.0/include/Api.hpp"
DependencyA* da = new DependencyA();
doSomething(da);
I get a compile error:
fatal error: 'Foo/DependencyA.hpp' file not found
I've tried building with:
clang -c mycode.cpp -isystem./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -isystem./foo-v1.0/include/ -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include/ -o mycode.o
and so on, to no avail.
How do I tell the compiler to resolve <Foo/**/*> to a particular root directory for every included file?
The answer is already in the comments.
To check include dirs one can use the method described here: What are the GCC default include directories? , preferably with - replaced with /dev/null:
clang -xc -E -v /dev/null
On my machine for clang it gives
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/clang/11.0.0/include
/usr/include
End of search list.
To discover how to manipulate this list, it suffices to read the gcc (or clang) manual (man clang or find it in the Internet, for example, https://man7.org/linux/man-pages/man1/gcc.1.html ). For gcc this reads:
Options for Directory Search
These options specify directories to search for header files, for
libraries and for parts of the compiler:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched
for header files during preprocessing. If dir begins with = or
$SYSROOT, then the = or $SYSROOT is replaced by the sysroot
prefix; see --sysroot and -isysroot.
Directories specified with -iquote apply only to the quote form
of the directive, "#include "file"". Directories specified with
-I, -isystem, or -idirafter apply to lookup for both the
"#include "file"" and "#include <file>" directives.
This description is followed by a detailed description of the order in which header files are searched and by some recommendations as to which option to use for which purpose. You'll find it in the manual. Search for "Options for Directory Search".
What I really don't like in your code is this line:
#include "/foo-v1.0/include/Api.hpp"
It seems to contain the absolute path to the header and I've never seen anything like this. I would change it to
#include "Api.hpp"
with /foo-v1.0/include being added to the search list via the usual compiler -I command-line option.
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 am learning to use make. I am trying to compile a program using g++ on my home machine that I have successfully compiled using xl on a school machine. I am trying to link with an external library that I built and placed in a separate directory. I am trying to include the header file, but g++ claims the include directory does not exist. The include directory definitely exists, tab complete fills it in and find locates it as well.
Why does g++ decide the directory does not exist? In general what causes a directory to be ignored? I want to know why this is breaking so I can better write makefiles. More importantly to me, how do I fix this and have g++ search for arbitrary header files in whatever directory I tell it to look in?
I have seen questions about g++ ignoring directories, but those were in the case of ignoring various system default locations. They usually solved their problem by removing a conflicting version or just re installing their tool. My problem is different because g++ is ignoring a user defined directory that actually exists.
src/a3.cc:1:17: fatal error: apf.h: No such file or directory
#include "apf.h"
$ find /home/USER/Documents/GitHub/core/apf/
/home/USER/Documents/GitHub/core/apf/
/home/USER/Documents/GitHub/core/apf/apfUserData.cc
....
/home/USER/Documents/GitHub/core/apf/apf.h
....
I have tried manually specifying the directory in the make file using -I
apf = /home/USER/Documents/Github/core/apf/
CFLAGS = $(CFLAGS) -Wall -g -I $(apf) --pedantic-errors --verbose
I have also tried setting CPLUS_INCLUDE_PATH
export CPLUS_INCLUDE_PATH = $(apf)
For each of these attempts I see the same error, that g++ is "ignoring nonexistant directory"
COLLECT_GCC=/usr/bin/g++
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/home/USER/Documents/Github/core/apf/"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../x86_64-redhat-linux/include"
ignoring duplicate directory "/usr/local/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
./inc
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/backward
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include
/usr/local/include
/usr/include
End of search list.
GNU C++ (GCC) version 4.9.2 20150212 (Red Hat 4.9.2-6) (x86_64-redhat-linux)
compiled by GNU C version 4.9.2 20150212 (Red Hat 4.9.2-6), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 954ba53e83b294b646fa1b6b73a69682
It appears that you have a case sensitive file system. You have GitHub in some places and Github in others. Make them all match correctly and you'll be in better shape.