Where are include files stored — Ubuntu Linux, GCC
the compiler, GCC in my case, knows where that stdio.h (and even the object file) are located on my hard drive. It just utilizes the files with no interaction from me. I think that on my Ubuntu Linux machine the files are stored at /usr/include/ . How does the compiler know where to look for these files? Is this configurable or is this just the expected default? Where would I look for this configuration? Since I’m asking a question on these include files, what are the source of the files? I know this might be fuzzy in the Linux community but who manages these? Who would provide and manage the same files for a Windows compiler. I was always under the impression that they come with the compiler but that was an assumption.
4 Answers 4
When the include file is in brackets the preprocessor first searches in paths specified via the -I flag. Then it searches the standard include paths (see the above link, and use the -v flag to test on your system).
When the include file is in quotes the preprocessor first searches in the current directory, then paths specified by -iquote, then -I paths, then the standard paths.
-nostdinc can be used to prevent the preprocessor from searching the standard paths at all.
Environment variables can also be used to add search paths.
When compiling if you use the -v flag you can see the search paths used.
gcc is a rich and complex «orchestrating» program that calls many other programs to perform its duties. For the specific purpose of seeing where #include «goo» and #include will search on your system, I recommend:
$ touch a.c $ gcc -v -E a.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. # 1 "a.c" This is one way to see the search lists for included files, including (if any) directories into which #include «. » will look but #include <. >won’t. This specific list I’m showing is actually on Mac OS X (aka Darwin) but the commands I recommend will show you the search lists (as well as interesting configuration details that I’ve replaced with . here;-) on any system on which gcc runs properly.
What are the GCC default include directories?
When I compile a very simple source file with gcc I don’t have to specify the path to standard include files such as stdio or stdlib. How does GCC know how to find these files? Does it have the /usr/include path hardwired inside, or it will get the paths from other OS components?
5 Answers 5
In order to figure out the default paths used by gcc / g++ , as well as their priorities, you need to examine the output of the following commands:
The credit goes to Qt Creator team.
Here’s a breakdown of the flags:
- -x selects the language, C or C++ respectively
- -E makes gcc to run the preprocessor only, so no compilation takes place
- -v prints all the commands run, which is the key to dumping the standard paths
- — is the «input file» to preprocess, as a convention — stands for stdin (or stdout, depending on the context); echo | feeds an empty string to gcc so effectively we preprocess an empty file generated on the fly
@Ihor — what does the — at the end of the command line do? I’ve seen questions about these dashes elesewhere on Stack Overflow, but their meaning varies by command. As far as I can tell when experimenting with Cygwin, it means gcc will do nothing and ignore all input except Ctrl-C. But gcc in an actual Bash shell might behave very differently.
@palapapa, I suppose it depends on the version of GCC. I tried omitting some of the flags from the above set, and even though there was some output each time, none of them contained the include . search starts here piece which is the one we are looking for. Running on Ubuntu 22.04, GCC 11.3.0
There is a command with a shorter output, which allows to automatically cut the include pathes from lines, starting with a single space:
$ echo | gcc -Wp,-v -x c++ - -fsyntax-only ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include" #include ". " search starts here: #include search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2 /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include /usr/local/include /usr/include End of search list. The credit goes to the libc++ front-page.
To summarise the other answers:
c++ -xc++ /dev/null -E -Wp,-v 2>&1 | sed -n ‘s,^ ,,p’
cc -xc /dev/null -E -Wp,-v 2>&1 | sed -n ‘s,^ ,,p’
Though I agree with Ihor Kaharlichenko’s answer for considering C++ and with abyss.7’s answer for the compactness of its output, they are still incomplete for the multi-arch versions of gcc because input processing depends on the command line parameters and macros.
echo | /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-g++ -specs=nano.specs -mcpu=cortex-m4 -march=armv7e-m -mthumb -mfloat-abi=soft -x c++ -E -Wp,-v\ — -fsyntax-only yields
⋮ /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../arm-none-eabi/include/newlib-nano /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1 /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi/thumb/v7e-m/nofp /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/include /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include ⋮ whereas echo | /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-g++ -x c++ -E -Wp,-v — -fsyntax-only yields
⋮ /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1 /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/include /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include ⋮ The former invocation utilizes newlib (see lines 1 and 3 of the output), the latter goes with the standard includes. The common files at the end of the list are an example for the usage of include_next .
Bottom line: Always consider all macros and compiler options when printing the include directories.
Detecting current gcc installation
In the sake of automatically-detecting native GCC installation from within a program, I would like to get the current path to gcc.exe or its root folder. But when I type gcc -print-prog-name=gcc it simply prints back gcc which is obviously not what I was expecting. How do I use gcc or other components supposedly installed on the system alongside gcc to retrieve the path to the gcc installation or executable?
Two questions there: para 1 and para 2. Best to ask one question at a time on SO since folks who can’t answer all will probably not answer any. That’s certainly where I am since it’s quite unclear what you are asking in para 2.
Actually set and echo %PATH% will not work, because the gcc installation is usually in PATH and from there one program cannot guess which path is to gcc.exe
1 Answer 1
For Linux at least, the «native GCC installation» might reasonably be interpreted as the GCC installation that is invoked through /usr/bin/gcc . But on that interpretation, there can be no doubt about its installation path.
Whenever you invoke gcc , if such a program is found at all, it is simply the first program called gcc that that is found in one of the directories listed in the value of environment variable PATH , in the environment of the invocation. True on Linux and other Unix-like OSes. True on Windows.
Imagine that gcc had an option —whereami that made it print its installation path on the standard output. The answer you will get will be the answer given by the first installation of gcc that is found in the operative PATH at the time of invocation. There might be any number of GCC installations on a system each of which will yield a different answer for gcc —whereami whenever that installation is the first to be discovered in the operative PATH .
Selection of different GCC installations via different PATH settings is commonplace on Windows, where the notion of «the native installation of GCC» has no meaning. But it is applicable on Linux too and sometimes used. The point is: no matter what command you run to find out where gcc is installed, any answer you get is in principle dependent on the operative PATH — unless you run the command with an absolute filename:
which of course amounts to deciding the answer before you ask the question.
The only cross-platform method by which you can discover the directory from which gcc will be run, if at all, by a command gcc . , is to get the operative PATH (programmatically, use getenv ), parse out the the directories it contains left to right and for successive directories query the filesystem for the existence of an executable gcc within it, stopping when you find one.
And since this can only give an answer for the operative PATH , and since the value of PATH needs parsed differently on Windows and Unix-like OSes, you might just as well invoke the OS-specific utility that does the same thing.
C:\>where gcc C:\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\gcc.exe And note that in the Windows case, I needed to select my mingw-w64 terminal environment to get an answer.
To execute commands and get their output programmatically, see How can I run an external program from C and parse its output?. On Windows, call _popen instead of popen .
Finding out what the GCC include path is [duplicate]
I’m trying to programmatically find the #include path on Linux, which as I understand it, in practice means finding what GCC considers it to be. (Is that quite true? How does Clang do it?) According to http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html some of the components involve the CPU architecture and the GCC version; the latter in particular seems tricky; I suppose it could be obtained by running gcc —version and parsing the output (or gcc -v ), but this seems inelegant at best and fragile at worst. Doing it from within one’s code assuming one’s program is being compiled with GCC might be another option, but it would require depending on that assumption. What’s the recommended way to do it?
2 Answers 2
will show the include path in use.
The cpp -Wp,-v command waits for some input. The echo | saves the user needing Ctrl + D or Ctrl + C to return to shell.
gcc -E -Wp,-v -xc /dev/null
I’m not sure what you mean by the recommended way to find the include path. The standard way is as given below (for c and c++):
$ `gcc -print-prog-name=cc1` -v ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include" #include ". " search starts here: #include search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed /usr/include End of search list. ^C $ `gcc -print-prog-name=cc1plus` -v ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include" #include ". " search starts here: #include search starts here: /usr/include/c++/4.7 /usr/include/c++/4.7/x86_64-linux-gnu /usr/include/c++/4.7/backward /usr/lib/gcc/x86_64-linux-gnu/4.7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed /usr/include End of search list. ^C