9

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)
user912083132
  • 127
  • 1
  • 1
  • 7
  • It is recursively looking at `/usr/include`.. What problem are you trying to solve? – Ramhound Oct 03 '15 at 20:04
  • It doesn't look like it recursively looks through. If it did, there would be no need to include the sys/ prefix. Including just ptrace.h, for example, does not work. – user912083132 Oct 03 '15 at 20:36
  • I don't think you included `/sys/ptrace.h` but `sys/ptrace.h`, right? – user253751 Oct 03 '15 at 22:16
  • This is almost certainly a bug in the "multiarch" patches to GCC. The directory `/usr/include/x86_64-linux-gnu` *is* being treated as a system include directory and *should* be included in the search-path list printed by `gcc -v`. I am not sure how someone managed to achieve that bug; if I remember correctly, the most obvious way to add system include directories does add them to what is printed by `-v`. (I wrote ~50% of GCC's preprocessor, but that was 15 years ago, so I may be misremembering something.) – zwol Oct 03 '15 at 23:02
  • @Ramhound It most definitely does *not* recursively search below `/usr/include`. That would break just about every C library in the world. – zwol Oct 03 '15 at 23:03
  • @user912083132 Hm, come to think of it, there's another possibility. Do you get a different search list printout if you do `echo '#include ' | gcc -fsyntax-only -xc -v -H -` ? The program `/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1` is not meant to be used directly. – zwol Oct 03 '15 at 23:06

2 Answers2

11

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.

Community
  • 1
Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
  • Why does x86_64-linux-gnu/ get shoved into the middle? – user912083132 Oct 03 '15 at 20:36
  • @user912083132: That's the `$TARGET` part I mentioned in my answer and comment. It's the output of `config.guess` when GCC was compiled, or which was given to its `configure` script with the `--target` flag. The real question is, how does that path get assembled? Does it just go back through the same list, appending `$TARGET` to each, after failing to find the header the first time through? – Warren Young Oct 03 '15 at 22:58
  • @user912083132 Updated my answer with some newly gleaned information. Please reread it; answer explains it comes from the CPP (C Pre-Processor). – Giacomo1968 Oct 04 '15 at 00:12
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 Giacomo1968 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.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Warren Young
  • 3,665
  • 3
  • 19
  • 28