Почему есть несколько копий файлов заголовка в / usr / включают в себя?

Нет, это не точные копии.

Если вы захотите разобраться, вы обнаружите, что файлы на верхнем уровне /usr/includeобычно содержат много #ifdefили других условных выражений, и они определяют только архитектуру -независимых частей. и будут #includeдругие вещи из архитектурных -каталогов, расположенных глубже в иерархии. Поскольку некоторые части, специфичные для архитектуры -, могут, в свою очередь, зависеть от некоторых частей, независимых от архитектуры -, может быть несколько уровней включения друг над другом.

Аналогично, файлы под /usr/include/c++будут иметь дополнительные объявления, которые будут иметь смысл только для C++, и #includeдля соответствующих C include-файлов, где это уместно.

Игра называется дедупликация для удобства сопровождения:цель состоит в том, чтобы, когда разработчику glibc нужно добавить что-то новое, что влияет только на ABI между приложением и glibc и не имеет -специфических частей архитектуры, добавление в идеале должно происходить только в одном месте дерева включаемых файлов, и оно будет действовать для всех аппаратных архитектур, использующих glibc. Или, скажем, когда в ядро ​​Linux добавляется новый системный вызов, будет место для его добавления, не затрагивая, например, *определения системных вызовов BSD или GNU Hurd. Или, если вы портируете glibc на другую аппаратную/ядерную архитектуру, вы найдете места, где можно подключить необходимые определения ABI ядра, не нарушая архитектурно -независимые вещи больше, чем это абсолютно необходимо.

Да, это довольно сложно.

У меня нет для вас простых ссылок, так как вся схема /usr/includeпредставляет собой сумму требований стандартов ISO C и POSIX и выбор, сделанный проектами GCC и glibc.

Я предлагаю вам записать ваш архитектурный триплет(x86_64-linux-gnuв вашем случае;можно получить с помощью gcc -dumpmachineна любой архитектуре, поддерживаемой GCC ), а затем изучить пути поиска файлов по умолчанию #include <...>компилятора.

Вы можете увидеть пути поиска с помощью:

• cpp -v /dev/null -o /dev/nullдля простого C
• cpp -x c++ -v /dev/null -o /dev/nullдля С++

У меня нет под рукой системы с GCC 7, но для GCC 6 список включаемых путей выглядит так для C:

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

... и так для C++:

...
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/x86_64-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
...

Если бы каталог /usr/local/include/<architecture triplet>существовал, он был бы добавлен в списки непосредственно перед /usr/local/include.

Таким образом, может показаться, что для ваших собственных проектов, если вам нужны версии включаемого файла, специфичные для архитектуры -, вы можете поместить их в /usr/[local/]include/<architecture triplet>/, а стандартные -независимые от архитектуры включаемые файлы /usr/[local/]include/. Я бы не стал трогать какие-либо включаемые каталоги, имя пути которых включает основной номер версии компилятора без очень веской причины.

Если вы планируете модифицировать glibcи не можете найти то, что вам нужно в glibcдокументации для разработчиков, вам лучше обратиться за советом в glibcсписок рассылки разработчиков; glibcявляется очень сложным, потому что его можно использовать также на архитектурах, которые используют компилятор, отличный от GCC, и поэтому могут не иметь соглашения о триплетах архитектуры в качестве стандарта.