How does gcc find the following header file?

Solution 1:

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.

Solution 2:

Short of delving into the GCC source code, I can't give you a "why", but I can tell you that the version of GCC I have here falls back to /usr/include/$TARGET after exhausting the choices you and JakeGould have found. You can see it like so:

$ strace -f -e open gcc -c foo.c -o foo.o 2>&1 | grep ptrace.h

where foo.c contains a #include <sys/ptrace.h>.

You need the -f argument here because gcc spawns children to do the actual compilation work. You need the 2>&1 because strace is writing its results to stderr, not stdout.

Notice you get ENOENT errors for all of the documented directories before it finally tries the one that succeeds.