Resposta mais curta.
Sua pergunta é sobre a saída de cc1 -v , mas isso não leva em consideração o CPP (C Pre-Processor) e os includes que são misturados em toda a cadeia de compilação. Se você executar cpp -v em seu sistema, uma mistura de inclusões será semelhante à saída de cc1 -v , mas com pelo menos o caminho /usr/include/x86_64-linux-gnu adicionado lá.
Resposta mais longa.
Since
/usr/include/x86_64-linux-gnu/is not contained in the first output, how does gcc findsys/ptrace.h?
Tecnicamente, /usr/include/x86_64-linux-gnu/ não é explicitamente definido na primeira saída, mas /usr/include/ é definitivamente. E esse é um caminho de pesquisa padrão conforme explicado na documentação oficial do GNU GCC :
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
E mais explicado aqui:
GCC looks for headers requested with
#include "file"first in the directory containing the current file, then in the directories as specified by-iquoteoptions, then in the same places it would have looked for a header requested with angle brackets. For example, if/usr/include/sys/stat.hcontains #include "types.h", GCC looks fortypes.hfirst in/usr/include/sys, then in its usual search path.
Isso implica que o caminho x86_64-linux-gnu/ é simplesmente inserido em /usr/include/*/sys/ da seguinte forma:
/usr/include/x86_64-linux-gnu/sys/ptrace.h
Pelo menos é o que eu pensava inicialmente em uma versão anterior desta questão . Mas depois de verificar este site , a explicação do que está acontecendo é um pouco mais detalhada e direta. resposta desse site para o conteúdo equivalente ao que eu postei acima é repostado abaixo; ênfase ousada é minha:
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
#includeand 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:
Saiba que o CPP (C Pre-Processor) é o primeiro passo no processo do compilador, vamos ver a saída "include" de cpp -v no meu sistema de testes do Ubuntu 12.04.5:
#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
Lá você pode ver claramente /usr/include/x86_64-linux-gnu . E para comparar, aqui está a saída “include” similar de /usr/lib/gcc/x86_64-linux-gnu/4.6/cc1 -v no mesmo sistema de teste do Ubuntu 12.04.5:
#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
Observe como /usr/include/x86_64-linux-gnu é claramente inserido na mistura pela ação inicial CPP (C Pre-Processor). E o post nesse site continua a explicar de onde vêm esses caminhos; mais uma vez a ênfase ousada é minha:
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.
Portanto, tudo se resume ao CPP (C Pre-Processor) sendo chamado como a primeira parte de uma cadeia de compilação C.