Linux – How does gcc find the following header file

gcclinux

I've included sys/ptrace.h into my C program.

The output of /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -v gives the following paths where gcc looks for header files

#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include
End of search list.

output of gcc -M for my program gives the following header file locations

    pt.o: pt.c /usr/include/stdc-predef.h /usr/include/stdio.h \
 /usr/include/features.h /usr/include/x86_64-linux-gnu/sys/cdefs.h \
 /usr/include/x86_64-linux-gnu/bits/wordsize.h \
 /usr/include/x86_64-linux-gnu/gnu/stubs.h \
 /usr/include/x86_64-linux-gnu/gnu/stubs-64.h \
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h \
 /usr/include/x86_64-linux-gnu/bits/types.h \
 /usr/include/x86_64-linux-gnu/bits/typesizes.h /usr/include/libio.h \
 /usr/include/_G_config.h /usr/include/wchar.h \
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h \
 /usr/include/x86_64-linux-gnu/bits/stdio_lim.h \
 /usr/include/x86_64-linux-gnu/bits/sys_errlist.h \
 /usr/include/x86_64-linux-gnu/sys/ptrace.h

Since /usr/include/x86_64-linux-gnu/ is not contained in the first output, how does gcc find sys/ptrace.h?

EDIT:

The output of echo '#include <sys/ptrace.h>' | gcc -fsyntax-only -xc -v -H - results in

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

Best Answer

Shorter answer.

Your question is about the output of cc1 -v, but that doesn’t factor in the CPP (C Pre-Processor) and it’s includes that are mixed into the whole compilation chain. If you run cpp -v on your system you should see, a mix of includes that looks similar to the output of cc1 -v but with at least the /usr/include/x86_64-linux-gnu path added in there.

Longer answer.

Since /usr/include/x86_64-linux-gnu/ is not contained in the first output, how does gcc find sys/ptrace.h?

Technically, /usr/include/x86_64-linux-gnu/ is not explicitly set in the first output, but /usr/include/ definitely is. And that is a default search path as explained in the official GNU GCC documentation:

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 <file> in:

  • /usr/local/include
  • libdir/gcc/target/version/include
  • /usr/target/include
  • /usr/include

And further explained here:

GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path.

So this implies that the x86_64-linux-gnu/ path is simply inserted into /usr/include/*/sys/ like this:

/usr/include/x86_64-linux-gnu/sys/ptrace.h

At least that is what I initially thought in an earlier version of this question. But after checking out this site the explanation of what is happening is a bit more detailed and the direct response from that site to the equivalent content to what I posted above is reposted below; bold emphasis is mine:

but that's sort of a wishy-washy answer (and also incomplete). Surely there must be a way to get GCC to tell you exactly where it's going to end up looking for its header files? Well, although it's convenient to think of GCC as a single monolithic application that takes in source code files and spits out working programs, it's technically a collection of other programs which chain together to produce the final compiled object file. The first of these is CPP, short for C Pre-Processor, whose job is to look for compiler directives like #include and modify the source code as specified by them; in the case of include, by copying the contents of another file into the current one. You can see where it looks for these files by passing it the -v flag:

Know that the CPP (C Pre-Processor) is the first step in the compiler’s process, let’s look at the “include” output of cpp -v on my Ubuntu 12.04.5 testing system:

#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include

In there you can clearly see /usr/include/x86_64-linux-gnu. And to compare, here is the similar “include” output of /usr/lib/gcc/x86_64-linux-gnu/4.6/cc1 -v on the same Ubuntu 12.04.5 testing system:

#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
 /usr/include

Note how /usr/include/x86_64-linux-gnu is clearly inserted into the mix by the initial CPP (C Pre-Processor) action. And the post on that site goes on further to explain where those paths come from; again bold emphasis is mine:

this path is actually built into CPP (which is part of GCC) at compile time; if for whatever reason you end up deleting one of those directories, it will still be checked for on each compile. Each directory is searched in the order it's listed here; if a file is found in /usr/local/include, the next three directories won't be checked.

So it all boils down to the CPP (C Pre-Processor) being called as the first part of a C compilation chain.

Related Question