主页 / unix / 问题 / 482669
Accepted
Adam Sperry
Asked: 2018-11-19 21:26:07 +0800 CST

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

  • 772

我一直在浏览我的 /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）。

c c++

1 个回答

  1. Best Answer

    不，它们不是精确的副本。

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

    同样，下面的文件/usr/include/c++将具有仅对 C++ 有意义的附加声明，并#include在适当的情况下为相应的 C 包含文件提供 s。

    游戏的名称是可维护性的重复数据删除：目的是当 glibc 开发人员需要添加仅影响应用程序和 glibc 之间的 ABI 并且没有特定于体系结构的部分的新内容时，理想情况下只需要添加一个包含文件树中的位置，它将对所有使用 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对于 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

    • 6

相关问题