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.
Best Answer
This was fixed by installing
libcrypt-devel.Then everything worked just fine... So problem solved!
This explains it better: Re: Difficult compiling Package::Stash::XS