☰

为什么/usr/include 中有多个头文件副本？

tag-icon • tag-icon c c++ linux-headers
为什么/usr/include 中有多个头文件副本？

我一直在浏览我的 /usr/include 文件夹，试图熟悉布局，并且我注意到有多个头文件副本（至少按名称，我实际上并没有对它们进行比较以查看它们是否准确）副本）在 /usr/include 的几个子目录中找到。对于标准 C 和 C++ 头文件以及 POSIX/LSB 标准头文件尤其如此。

一些示例包括（注意 ./ 指 /usr/include）：

./asm-generic/unistd.h
./linux/unistd.h
./unistd.h
./x86_64-linux-gnu/sys/unistd.h
./x86_64-linux-gnu/bits/unistd.h
./x86_64-linux-gnu/asm/unistd.h

./stdlib.h
./x86_64-linux-gnu/bits/stdlib.h
./c++/7/stdlib.h
./c++/7/tr1/stdlib.h

./c++/7/cmath
./c++/7/ext/cmath
./c++/7/tr1/cmath

./asm-generic/termios.h
./linux/termios.h
./x86_64-linux-gnu/sys/termios.h
./x86_64-linux-gnu/bits/termios.h
./x86_64-linux-gnu/asm/termios.h
./termios.h

./linux/time.h
./time.h
./x86_64-linux-gnu/sys/time.h
./x86_64-linux-gnu/bits/time.h

为什么是这样？为什么一些 C 标准头文件出现在 C++ 位置？

我只安装了一个编译器（GCC 7）。

答案1

不，它们不是精确的复制品。

如果您愿意调查，您会发现顶层的文件/usr/include通常会有很多#ifdefs 或其他条件，并且它们只会定义与体系结构无关的部分，并且会定义#include更深层的体系结构特定目录中的其他内容层次结构。由于一些特定于体系结构的部分可能又依赖于一些与体系结构无关的部分，因此可能存在彼此之上的多层包含。

同样，下面的文件/usr/include/c++将具有仅对 C++ 有意义的附加声明，而#includes 则适用于相应的 C 包含文件。

游戏的名字是重复数据删除以提高可维护性：目的是当 glibc 开发人员需要添加一些新内容时，仅影响应用程序和 glibc 之间的 ABI，并且没有特定于体系结构的部分，理想情况下，添加只需要发生在包含文件树中的一个位置，并且它将对所有使用 glibc 的硬件架构生效。或者，例如，当一个新的系统调用添加到 Linux 内核时，将有一个地方可以添加它，而不会干扰 *BSD 或 GNU Hurd 系统调用定义。或者，如果您要将 glibc 移植到另一个硬件/内核体系结构，您会发现可以插入必要的内核 ABI 定义的位置，而不会干扰与体系结构无关的内容（除非绝对必要）。

是的，这非常复杂。

我没有任何简单的参考资料可供您参考，因为整个/usr/include布局是 ISO C 和 POSIX 标准要求以及 GCC 和 glibc 项目做出的选择的总和。

我建议你记下你的建筑三联体（x86_64-linux-gnu在您的情况下；可以在gcc -dumpmachineGCC 支持的任何体系结构上获得），然后研究编译器的默认#include <...>文件搜索路径。

您可以通过以下方式查看搜索路径：

  • cpp -v /dev/null -o /dev/null对于普通 C
  • cpp -x c++ -v /dev/null -o /dev/null对于 C++

我手头没有带有 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上寻求建议；非常复杂，因为它也可以在使用 GCC 以外的编译器的体系结构上使用，因此可能没有体系结构三元组约定作为标准。glibcglibc

相关内容