Building C++ file with g++ in Windows not working as .bat - c++

Good morning,
I am a new user of Windows (+10 years using Linux) and for some reason I have to compile a C++ program. I do not have a big experience in debugging in Windows, but I am eager to understand what I do wrong.
I use MinGW with g++ and different libraries, particularly one called libjpeg.
When I compile & build the file in a PowerShell using the following command, everything works fine, and my C++ code gives me the expected results.
g++ -o imageProcessing imageProcessing.cpp -lgdi32 -Dgmic_use_jpeg -I'C:\GnuWin32\include' -L'C:\GnuWin32\lib' -ljpeg
When I use the exact same command in a .bat file, or directly in my C++ editor (geany), I have this error:
imageProcessing.cpp:6:21: fatal error: jpeglib.h: No such file or directory
#include <jpeglib.h>
^
compilation terminated.
It doesn't find the jpeglib.h.
The correct path were set in the environmental variables.
The libjpeg I use allows me to open/save jpeg pictures when I use the CImg library. It can be found here:
Jpeg for Windows
Here is a very simple example:
#include <iostream>
#include <jpeglib.h>
using namespace std;
int main() {
float number;
cout << "Enter a number: ";
cin >> number;
}
Let's call this test.cpp and its location is: C:\Users\Rémi\Documents\Image_Procesing\C++\testCImg
Here is what I've added in my environmental variables path: C:\GnuWin32\lib;C:\GnuWin32\bin;C:\MinGW\bin;
Here is my test.bat: g++ -o test test.cpp -lgdi32 -Dgmic_use_jpeg -I'C:\GnuWin32\include' -L'C:\GnuWin32\lib' -ljpeg
test.bat is also located in: C:\Users\Rémi\Documents\Image_Procesing\C++\testCImg
the .bat fail is the following:
C:\Users\Rémi\Documents\Image_Procesing\C++\testCImg>g++ -o test test.cpp -lgdi32 -Dgmic_use_jpeg -I'C:\GnuWin32\include
' -L'C:\GnuWin32\lib' -ljpeg
test.cpp:3:21: fatal error: jpeglib.h: No such file or directory
#include <jpeglib.h>
^
compilation terminated.
I spent all my day yesterday trying to figure it out, and I am limited by my Windows knowledge.
If someone could help me, I would appreciate it very much.
Thank you.

When you have include path problems, ask GCC to tell you what it's using.
In the below example, you can clearly see that it's searching for a location 'test' and ignoring it for not existing.
You can then deduce that, as mentioned elsewhere, the single quotes are wrong in Batch. At that point you'd give "test" a go and achieve success.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\lightness>g++ -E -x c++ - -v -I'test'
Using built-in specs.
COLLECT_GCC=g++
Target: mingw32
Configured with: ../../src/gcc-4.7.1/configure --build=mingw32 --enable-language
s=c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enabl
e-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-sp
ecific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disab
le-symvers --disable-build-poststage1-with-cxx --disable-werror --prefix=/mingw3
2tdm --with-local-prefix=/mingw32tdm --enable-cxx-flags='-fno-function-sections
-fno-data-sections' --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugu
rl=http://tdm-gcc.tdragon.net/bugs
Thread model: win32
gcc version 4.7.1 (tdm-1)
COLLECT_GCC_OPTIONS='-E' '-v' '-I' ''\''test'\''' '-mtune=i386' '-march=i386'
c:/mingw32/bin/../libexec/gcc/mingw32/4.7.1/cc1plus.exe -E -quiet -v -I 'test'
-iprefix c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/ - -mtune=i386 -march=i386
ignoring nonexistent directory "c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/../../..
/../mingw32/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/inc
lude/c++"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/inc
lude/c++/mingw32"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/inc
lude/c++/backward"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/inc
lude"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/../
../../../include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/inc
lude-fixed"
ignoring nonexistent directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/.
./../../../mingw32/include"
ignoring nonexistent directory "'test'"
#include "..." search starts here:
#include <...> search starts here:
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++/mingw32
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++/backward
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/../../../../include
c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include-fixed
End of search list.
# 1 "<stdin>"

Argument tokens in Windows traditionally use the " character. I'm thinking the single quotes are being interpreted as part of the path names, resulting in the "no such file or directory" errors. That would explain why it works in PowerShell, though, as single quotes are valid there.
See if you have better luck with this:
g++ -o imageProcessing imageProcessing.cpp -lgdi32 -Dgmic_use_jpeg -I"C:\GnuWin32\include" -L"C:\GnuWin32\lib" -ljpeg

Related

Compile C++ on Windows

I'm trying to compile C++ on Windows.
The command needed to compile on Linux is:
g++ -O3 -Wall -shared -std=c++11 -fPIC `python -m pybind11 --includes` EO_functions_bipartite.cpp -o extremal_bi.so
I installed MinGW but when I try to compile I get the following error:
g++.exe: error: python: No such file or directory
g++.exe: error: pybind11: No such file or directory
g++.exe: error: unrecognized command line option '-m'
g++.exe: error: unrecognized command line option '--includes EO_functions_bipartite.cpp'
g++.exe: fatal error: no input files
compilation terminated.
Assuming you have python in your path.
The backtick escape thing that embeds the python -m pybind11 --includes command within the g++ doesn't work on cmd.exe in Windows.
Run the python -m pybind11 --includes command on its own line in the cmd shell. Take the output of that command and substitute in into the g++ command. It should be a bunch of -I include params.
So if the output of the python command is this:
-IC:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0\Include -IC:\Users\User\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pybind11\include
Expand your g++ command to be this:
g++ -O3 -Wall -shared -std=c++11 -fPIC "-IC:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0\Include" -IC:\Users\User\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pybind11\include EO_functions_bipartite.cpp -o extremal_bi.so
Notice the quotes I put around the first include directory because it has a space in its path.
The easiest way to start on native Windows if you have a Linux background is to install MSYS2 shell with MinGW-w64. This will provide an actual bash that allows you to run commands almost exactly the same way as on Linux, including support for backticks like in the case of your issue.
Though I would always recommend using $( ... ) instead of backticks, as this allows nesting.
Note that MinGW-w64 also exists on Windows to allow cross-building for Windows from Linux, but that may be a bit more difficult if you have never done any cross-building before.
Also -shared ... -o extremal_bi.so in your command should be replaced with -shared ... -o extremal_bi.dll -Wl,--out-implib,libextremal_bi.dll.a as .so files don't exist on Windows as Windows uses .dll files for shared libraries and the compiler uses .dll.a files as library objects for them.
Finally on Windows you need to tell the compiler or linker which symbols you will be exporting by either writing a libextremal_bi.def starting with the line EXPORTS followed all the symbols you want to be exported and include -def libextremal_bi.def in the link command, or using __declspec(dllexport)/__declspec(dllimport) when defining those symbols, which may be a bit complexer as it requires some conditional defines to determine if the code is being compiled for Windows and if it's during the actual build process of the shared library (__declspec(dllexport)) or code that uses it (__declspec(dllimport)). There is also another method to export all symbols, but that's a dirty method that may more easily cause symbol conflicts.

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

After upgrading to Catalina from Mojave, Setuping: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk in the env.
I'm unable to compile a program that use <cmath> header.
I tried changing CFLAGS, CCFLAGS, CXXFLAGS to point to the MacOSSDK Location that change nothing
Scanning dependencies of target OgreMain
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f OgreMain/CMakeFiles/OgreMain.dir/build.make OgreMain/CMakeFiles/OgreMain.dir/build
[ 0%] Building CXX object OgreMain/CMakeFiles/OgreMain.dir/src/OgreASTCCodec.cpp.o
cd /Users/roman/Downloads/ogre-1.12.2/build/OgreMain && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DOgreMain_EXPORTS -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OSX -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/include/Threading -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/src -I/Users/roman/Downloads/ogre-1.12.2/build/Dependencies/include -I/Users/roman/Downloads/ogre-1.12.2/OgreMain/include -I/Users/roman/Downloads/ogre-1.12.2/build/include -I/Users/roman/Downloads/ogre-1.12.2/OgreMain -isystem /usr/local/include -Wall -Winit-self -Wcast-qual -Wwrite-strings -Wextra -Wundef -Wmissing-declarations -Wno-unused-parameter -Wshadow -Wno-missing-field-initializers -Wno-long-long -Wno-inconsistent-missing-override -msse -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -o CMakeFiles/OgreMain.dir/src/OgreASTCCodec.cpp.o -c /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreASTCCodec.cpp
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreASTCCodec.cpp:29:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/src/OgreStableHeaders.h:40:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/include/OgrePrerequisites.h:309:
In file included from /Users/roman/Downloads/ogre-1.12.2/OgreMain/include/OgreStdHeaders.h:10:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9: error: no member named 'signbit' in the global namespace
using ::signbit;
~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:315:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:316:9: error: no member named 'isfinite' in the global namespace; did you mean 'finite'?
using ::isfinite;
for example the macro: isless is present in the global namespace and on my computer:
➜ cat math.h | grep "isless"
#define isless(x, y) __builtin_isless((x),(y))
#define islessequal(x, y) __builtin_islessequal((x),(y))
#define islessgreater(x, y) __builtin_islessgreater((x),(y))
➜ pwd
/usr/local/include
➜
Even the cmath header include it:
➜ cat /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath | grep "math.h"
#include <math.h>
And my command line have the option -isystem /usr/local/include
This should work...
I'm curious: What compiler are you using? What's the value of CMAKE_OSX_SYSROOT?
I'm fairly convinced this is the result of a wrong CMAKE_OSX_SYSROOT. I had the problem you're describing when using python bindings for clang (where CMake doesn't manage the compiler call), but I managed to recreate the error in CMake by doing:
set(CMAKE_OSX_SYSROOT "") # Reset.
I solved my problem by following the answers to this question: Cannot compile R packages with c++ code after updating to macOS Catalina.
To summarise: On Catalina, /usr/include is purged and protected by SIP. Thus, any project that expects the C headers to be found there will fail to compile. If I remember correctly, Apple recommends to file bug reports to projects that expect C headers in /usr/include.
You must point the build system of the code you're trying to compile to the right headers:
(1) Make sure Xcode is up to date. There's no telling what an outdated Xcode on Catalina might do to your build environment.
(2) Use the -isysroot /sdk/path compiler flag, where /sdk/path is the result of xcrun --show-sdk-path. I'm not sure what CMake's best practice is, but try doing
set(CMAKE_OSX_SYSROOT /sdk/path)
or
set(CMAKE_CXX_FLAGS "[...] -isysroot /sdk/path")
If that solves the problem, you may want to look for a better way to do this in CMake.
Of course, if you're adventurous, you could also disable SIP, as suggested in the answer to my question: /usr/include missing on macOS Catalina (with Xcode 11)
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.

G++ linking batch PATH

I have 2 different g++ compilers on my computer:
one in the standard directory (C:\MinGW),
and one is a portable distribution.
Now I'm trying to link a c++ project.
The problem is, it is linked against boost libraries
compiled with the portable distribution of g++. The standard
installation directory is ofcourse included in the PATH environment
variable. So when I try to compile my project it will produce linker errors.
I tried to create a batch file which added the portable version's directory at the beginning of the PATH variable. With no luck. Maybe some one can help me out?
#echo off
set PATH=%~dp0..\c++\compiler\bin;%PATH%
REM cd /d "%~dp0"
..\c++\compiler\bin\g++ main.cpp ^
-std=c++0x -static-libgcc -static-libstdc++ ^
-I"../c++/include" ^
-L"../c++/lib" ^
-l"boost_serialization-mgw46-mt-1_52" ^
-l"boost_system-mgw46-mt-1_52" ^
-o output.exe -W -O2
pause
Note: I used "..\c++\compiler\bin\" befor the g++ command because I wanted to be sure it it used the right path, but ofcourse it doesn't work the way I expected.
Solved it by recompiling boost with the installed version of GCC.

MinGW won't compile, Error 1

Making a simple hello world app in c++, but it won't compile. I have the folder C:\WiiGames\e3\ with the files main.cpp and Makefile. My makefile is:
build: main.cpp
C:/MinGW/bin/g++.exe main.cpp -o e3.exe
My error is:
C:\WiiGames\e3>make build
C:/MinGW/bin/g++.exe main.cpp -o e3.exe
make: *** [build] Error 1
C:\WiiGames\e3>
Any help would be greatly appreciated.
My code:
#include <iostream>
#include <stdio.h>
#include <string>
#include <cmath>
#include <cstdlib>
#include <time.h>
int main() {
printf("Hello World!");
}
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
Make sure it is a tab rather than spaces in the make file before the c:/mingw... Line. It looks like it is make giving the error, not g++.
What happens when you run g++.exe main.cpp -o e3.exe on the command line directly? If nothing happens, is g++ in your path? I'd start by making sure that g++ is setup and in your path.
Yes, it's an old question. These are some solutions i came across (YMMV a lot):
Check if your paths start with c:/ as opposed to /c/ or vice-versa.
Check if you're running in the right shell, i.e., one of:
c:\msys64\msys2_shell.cmd -mingw32
c:\msys64\mingw32.exe
c:\msys64\usr\bin\bash.exe
which may differ if used within an IDE.

Where does gcc look for C and C++ header files?

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.