glibc 知：手册83：附录D：库维护

原创

已于 2022-06-05 23:05:31 修改 · 437 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#glibc

于 2022-06-05 20:49:29 首次发布

本文详细介绍了GNU C库的维护过程，包括添加新功能、处理平台特定的类型、宏和函数，以及64位时间符号的移植策略。重点讲解了库的结构、移植步骤和配置文件管理，为移植到Unix系统提供实用指导。

文章目录

1. 前言
2. 附录 D 库维护
3. 参考

1. 前言

The GNU C Library Reference Manual for version 2.35

2. 附录 D 库维护

Appendix D Library Maintenance

2.1. 添加新功能

Adding New Functions

构建库的过程是由 makefile 驱动的，它大量使用了 GNU make 的特殊功能。makefile 非常复杂，您可能不想尝试理解它们。但是他们所做的相当简单，只需要您在正确的位置定义一些变量。

库源分为子目录，按主题分组。

string 子目录有所有的字符串操作函数，math 有所有的数学函数，等等。

每个子目录都包含一个简单的 makefile，称为 Makefile，它定义了一些 make 变量，然后包含全局 makefile 规则，其中一行如下：

include …/Rules
子目录 makefile 定义的基本变量是：

subdir
子目录的名称，例如 stdio。必须定义此变量。

headers
库的这一部分中的头文件的名称，例如stdio.h。

routines
aux
库的这一部分中的模块（源文件）的名称。这些应该是简单的名称，例如“strlen”（而不是完整的文件名，例如 strlen.c）。对在库中定义函数的模块使用例程，对包含数据定义等内容的辅助模块使用 aux。但是routines和aux的值只是串联起来的，所以实际上并没有什么区别。

tests
库的这一部分的测试程序的名称。这些应该是简单的名称，例如“tester”（而不是完整的文件名，例如 tester.c）。‘make tests’ 将构建并运行所有的测试程序。如果测试程序需要输入，请将测试数据放入名为 test-program.input 的文件中；它将在其标准输入上提供给测试程序。如果测试程序想要使用参数运行，请将参数（全部放在一行上）放在名为 test-program.args 的文件中。当测试通过时，测试程序应该以零状态退出，当测试表明库中存在错误或构建错误时，测试程序应该以非零状态退出。

others
与库的这一部分关联的“其他”程序的名称。这些程序本身不是测试，而是库中包含的其他小程序。它们是通过“制造他人”建造的。

install-lib
install-data
install
要通过“make install”安装的文件。‘install-lib’ 中列出的文件安装在 configparms 或 Makeconfig 中的 ‘libdir’ 指定的目录中（请参阅安装 GNU C 库）。install-data 中列出的文件安装在 configparms 或 Makeconfig 中的“datadir”指定的目录中。install 中列出的文件安装在 configparms 或 Makeconfig 中的 ‘bindir’ 指定的目录中。

distribute
此子目录中的其他文件应放入分发 tar 文件中。您无需在此处列出 makefile 本身或其他标准变量中列出的源文件和头文件。仅当存在应进入分发的不寻常方式使用的文件时才定义分发。

generated
Makefile 在此子目录中生成的文件。这些文件将被“make clean”删除，它们永远不会进入发行版。

extra-objs
Makefile 在此子目录中构建的额外目标文件。这应该是一个文件名列表，例如 foo.o；这些文件实际上会在任何正在构建的目录对象文件中找到。这些文件将被“make clean”删除。此变量用于构建其他对象或测试所需的辅助对象文件。

2.1.1. 平台特定类型、宏和函数

Platform-specific types, macros and functions

有时需要向开发人员提供非标准的、特定于平台的功能。C 库传统上是最低的库层，因此它提供这些低级特性是有意义的。但是，如果另一个包提供了这些功能，那么在 C 库中包含这些功能可能是不利的，并且它们的两个版本会相互冲突。此外，这些功能不适用于不使用 GNU C 库但使用其他 GNU 工具（如 GCC）的项目。

目前的指导方针是：

如果头文件提供的功能仅在特定机器架构上有意义并且与操作系统无关，那么这些功能最终应该作为 GCC 内置函数提供。在那之前，GNU C 库可能会在头文件中提供它们。当 GCC 内置函数可用时，头文件中提供的那些应该在内置函数可用的 GCC 版本之前有条件地可用。
如果头文件提供特定于操作系统的功能，GCC 和 GNU C 库都可以提供，但首选 GNU C 库，因为它已经有很多关于操作系统的信息。
如果头文件提供了特定于操作系统但被 GNU C 库使用的特性，那么 GNU C 库应该提供它们。

提供低级特征的一般解决方案是将它们导出如下：

定义宏和内联函数的非标准低级头文件应称为 sys/platform/name.h。
每个头文件的名称都应该包含平台名称，以避免用户认为不同平台的不同头文件之间有任何共同点。例如，像 sys/platform/ppc.h 这样的 sys/platform/arch.h 名称比 sys/platform.h 更好。
GNU C 库提供的特定于平台的头文件应与 GCC 协调，以便在可用时首选编译器内置版本的函数和宏。这意味着用户程序只需要包含 sys/platform/arch.h，为了方便和可移植性，保持相同的类型、宏和函数名称。
每个包含的符号必须具有前缀 _arch，例如 __ppc_get_timebase。

提供头文件的最简单方法是将其添加到 sysdep_headers 变量中。例如，PowerPC 上特定于 Linux 的头文件的组合可以这样提供：