glibc 知：手册82：附录C：安装 GNU C 库

文章目录

• 1. 前言
• 2. 附录 C 安装 GNU C 库
• • 2.1. 配置和编译 GNU C 库
  • 2.2. 安装 C 库
  • 2.3. 推荐的编译工具
  • 2.4. 针对 GNU/Linux 系统的具体建议
  • 2.5. 报告错误
• 3. 参考

1. 前言

The GNU C Library Reference Manual for version 2.35

2. 附录 C 安装 GNU C 库

Appendix C Installing the GNU C Library

在您执行任何其他 *** 作之前，您应该阅读 https://sourceware.org/glibc/wiki/FAQ 上的常见问题解答。它回答了常见问题并描述了您在编译和安装时可能遇到的问题。

您将需要几个 GNU 工具的最新版本：肯定是 GCC 和 GNU Make，可能还有其他工具。请参阅下面的推荐编译工具。

2.1. 配置和编译 GNU C 库

Configuring and compiling the GNU C Library

GNU C 库不能在源目录中编译。您必须在单独的构建目录中构建它。例如，如果您在 /src/gnu/glibc-version 中解压了 GNU C 库源代码，请创建一个目录 /src/gnu/glibc-build 来放置目标文件。这允许删除整个构建目录，以防万一发生错误，这是重新开始的最安全方法，应该始终这样做。

在您的对象目录中，运行位于源代码树顶层的 shell 脚本配置。在上面的场景中，你会输入

$ ../glibc-version/configure args...

请注意，即使您在单独的构建目录中构建，编译可能需要在源目录中创建或修改文件和目录。

configure 有很多选项，但通常唯一必须的选项是“–prefix”。这个选项告诉 configure 你想把 GNU C 库安装在哪里。这默认为 /usr/local，但作为标准系统库安装的正常设置是 GNU/Linux 系统的“–prefix=/usr”和 GNU/Hurd 系统的“–prefix=”（一个空前缀） .

传递 ‘CC=compiler’ 和 CFLAGS=flags 参数来配置也可能很有用。CC 选择将使用的 C 编译器，CFLAGS 为编译器设置优化选项。所有编译所需的任何编译器选项，例如选择 ABI 或为其生成代码的处理器的选项，都应包含在 CC 中。GNU C 库构建系统可能会为特定文件覆盖的选项（例如优化和调试）应该放在 CFLAGS 中。CFLAGS 的默认值为‘-g -O2’，GNU C 库不经过优化就无法编译，因此如果指定了 CFLAGS，则必须启用优化。例如：

$ ../glibc-version/configure CC="gcc -m32" CFLAGS="-O3"

以下列表描述了配置的所有可用选项：

‘–prefix=directory’
在目录的子目录中安装与机器无关的数据文件。默认安装在 /usr/local 中。

‘–exec-prefix=directory’
在目录的子目录中安装库和其他机器相关文件。如果指定了该选项，则默认为“–prefix”目录，否则为 /usr/local。

‘–with-headers=directory’
在目录中查找内核头文件，而不是 /usr/include。GNU C 库需要来自内核头文件的描述内核接口的信息。GNU C 库通常会在 /usr/include 中查找它们，但如果您指定此选项，它将改为在 DIRECTORY 中查找。

此选项主要用于 /usr/include 中的头文件来自旧版本的 GNU C 库的系统。在这种情况下，偶尔会发生冲突。如果您想使用一组比 /usr/include 中找到的更新的内核头文件来编译 GNU C 库，您也可以使用此选项。

‘–enable-kernel=version’
此选项目前仅在 GNU/Linux 系统上有用。version 参数的格式应为 X.Y.Z，并描述生成的库预期支持的 Linux 内核的最小版本。版本号越高，添加的兼容代码越少，代码越快。

‘–with-binutils=directory’
使用目录中的 binutils（汇编器和链接器），而不是 C 编译器默认使用的那些。如果您系统上的默认 binutils 无法处理 GNU C 库中的所有结构，您可以使用此选项。在这种情况下，configure 会检测到问题并抑制这些结构，这样库仍然可以使用，但功能可能会丢失——例如，您不能使用旧的 binutils 构建共享 libc。

–with-nonshared-cflags=cflags’
使用额外的编译器标志 cflags 来构建库的部分，即使使用共享链接（即包含在 lib*_nonshared.a 库中的目标文件），这些部分也始终静态链接到应用程序和库中。构建过程将自动使用适当的标志，但此选项可用于设置构建应用程序和库所需的附加标志，以匹配本地策略。例如，如果此类策略要求所有链接到应用程序的代码必须使用源代码强化构建，‘–with-nonshared-cflags=-Wp,-D_FORTIFY_SOURCE=2’ 将确保编译 libc_nonshared.a 中的对象使用此标志（尽管在这种特殊情况下这不会影响生成的代码，并且可能仅更改调试信息和元数据）。

‘–with-rtld-early-cflags=cflags’
使用额外的编译器标志 cflags 来构建动态链接器的早期启动代码。这些标志可用于启用早期动态链接器诊断，以便在与 GNU C 库的其余部分不兼容的 CPU 上运行，例如，由于编译器标志针对后来的指令集架构 (ISA)。

‘–with-timeoutfactor=NUM’
指定一个整数 NUM 来调整测试程序的超时时间。可以使用 TIMEOUTFACTOR 环境变量在运行时更改此因素。

‘–disable-shared’
即使可能，也不要构建共享库。并非所有系统都支持共享库；您需要 ELF 支持和（当前）GNU 链接器。

‘–disable-default-pie’
不要将 glibc 程序和测试套件构建为与位置无关的可执行文件 (PIE)。默认情况下，glibc 程序和测试在支持它的目标上创建为与位置无关的可执行文件。如果工具链和架构支持它，静态可执行文件将构建为静态 PIE，生成的 glibc 可以与 GCC 选项 -static-pie 一起使用，该选项可用于 GCC 8 或更高版本，以创建静态 PIE。

‘–enable-cet’
‘–enable-cet=permissive’
启用英特尔控制流强制技术 (CET) 支持。当使用 --enable-cet 或 --enable-cet=permissive 构建 GNU C 库时，生成的库受到间接分支跟踪 (IBT) 和影子堆栈 (SHSTK) 的保护。启用 CET 后，GNU C 库与所有现有的可执行文件和共享库兼容。此功能目前在 i386、x86_64 和 x32 上支持 GCC 8 和 binutils 2.29 或更高版本。请注意，启用 CET 后，GNU C 库需要能够支持多字节 NOP 的 CPU，例如 x86-64 处理器以及 Intel Pentium Pro 或更新版本。使用 --enable-cet，在启用 CET 的应用程序中 dlopen 未启用 CET 的共享库是错误的。使用 --enable-cet=permissive 时，在启用 CET 的应用程序中 dlopening 未启用 CET 的共享库时禁用 CET。

注意： --enable-cet 已在非 CET 处理器上针对 i686、x86_64 和 x32 进行了测试。–enable-cet 已在 CET 处理器上针对 i686、x86_64 和 x32 进行了测试。

‘–enable-memory-tagging’
如果体系结构支持，则启用内存标记支持。当使用此选项构建 GNU C 库时，生成的库将能够在存在硬件支持时通过使用可调参数“glibc.mem.tagging”来控制标记内存的使用。这包括在使用 malloc API 时生成标记内存。

目前只有具有 MTE 的 AArch64 平台提供此功能，尽管该库仍将在旧版本的架构上运行（没有内存标记）。

默认是禁用对内存标记的支持。

‘–disable-profile’
不要使用分析信息构建库。如果您不打算进行分析，您可能想要使用此选项。

‘–enable-static-nss’
编译 NSS（名称服务切换）库的静态版本。不推荐这样做，因为它违背了 NSS 的目的；与 NSS 库静态链接的程序不能动态重新配置以使用不同的名称数据库。

‘–enable-hardcoded-path-in-tests’
默认情况下，动态测试与安装的 C 库一起运行。此选项在动态测试中对新建的 C 库路径进行硬编码，以便可以直接调用它们。

‘–disable-timezone-tools’
默认情况下，与时区相关的实用程序（zic、zdump 和 tzselect）随 GNU C 库一起安装。如果您正在独立构建这些（例如，通过使用“tzcode”包），那么此选项将允许禁用这些的安装。

请注意，您需要确保外部工具与 GNU C 库所期望的版本保持同步，因为数据格式可能会随着时间而改变。有关更多详细信息，请参阅时区子目录。

‘–enable-stack-protector’
‘–enable-stack-protector=strong’
‘–enable-stack-protector=all’
使用 GCC -fstack-protector、-fstack-protector-strong 或 -fstack-protector-all 选项编译 C 库和 glibc 包的所有其他部分（包括线程和数学库、NSS 模块和音译模块）以检测堆栈溢出。只有动态链接器和少量直接从汇编器调用的例程不受此保护。

‘–enable-bind-now’
禁用已安装共享对象和程序的延迟绑定。这提供了额外的安全强化，因为它启用了完整的 RELRO 和只读的全局偏移表 (GOT)，但代价是稍微增加了程序加载时间。

‘–enable-pt_chown’
文件 pt_chown 是 grantpt 的辅助二进制文件（请参阅 Pseudo-Terminals），它安装了 setuid root 以修复 GNU/Hurd 上的伪终端所有权。它在 GNU/Linux 上不是必需的，并且 GNU C 库在使用 --enable-pt_chown 配置时不会使用已安​​装的 pt_chown 程序。

‘–disable-werror’
默认情况下，GNU C 库是使用 -Werror 构建的。如果您希望在不使用此选项的情况下进行构建（例如，如果使用比此版本的 GNU C 库测试的新版本的 GCC 构建，那么新的警告会导致使用 -Werror 的构建失败），您可以配置 - -禁用错误。

‘–disable-mathvec’
默认情况下，对于 x86_64，GNU C 库是使用向量数学库构建的。使用此选项禁用向量数学库。

‘–enable-tunables’
可调参数支持允许在运行时自定义其他库参数。默认情况下启用此功能。此选项可以采用以下值：

yes
如果未将选项传递给配置，则这是默认设置。这将启用可调参数并选择默认前端（当前为“valstring”）。

no
此选项禁用可调参数。

valstring
这将启用可调参数并为可调参数选择“valstring”前端。此前端允许用户在单个环境变量 GLIBC_TUNABLES 中将可调参数指定为冒号分隔的列表。

‘–disable-crypt’
不要安装密码哈希库 libcrypt 或头文件 crypt.h。unistd.h 仍将声明函数 crypt。使用此选项不会更改可能需要与 -lcrypt 链接的程序集；这仅意味着 GNU C 库不会提供该库。

此选项适用于尝试独立维护的 libcrypt 实现的黑客和发行版。在未来的版本中，它可能会成为默认值。

‘–disable-experimental-malloc’
默认情况下，在 malloc 中启用了每线程缓存。虽然可以使用可调参数（将 glibc.malloc.tcache_count 设置为零）在每个应用程序的基础上禁用此缓存，但此选项可用于将其从构建中完全删除。

‘–disable-scv’
禁用对系统调用使用 scv 指令。即使内核支持 scv，所有系统调用都将使用 sc。仅限 PowerPC。

‘–build=build-system’
‘–host=host-system’
这些选项用于交叉编译。如果您指定了这两个选项并且 build-system 与 host-system 不同，则 configure 将准备从 build-system 交叉编译 GNU C 库以在 host-system 上使用。您可能还需要“–with-headers”选项，并且您可能必须覆盖 configure 对编译器和/或 binutils 的选择。

如果您只指定“–host”，configure 将为本地编译做准备，但使用您指定的内容，而不是猜测您的系统是什么。这对于更改 CPU 子模型最有用。例如，如果 configure 猜测你的机器是 i686-pc-linux-gnu 但你想为 586es 编译一个库，给 ‘–host=i586-pc-linux-gnu’ 或者只是 ‘–host=i586-linux ’ 并向 CC 添加适当的编译器标志（’-mcpu=i586’ 就可以了）。

如果您只指定“–build”，configure 会感到困惑。

‘–with-pkgversion=version’
指定正在构建的二进制文件的描述，可能包括构建号或构建日期，以包含在与 GNU C 库一起安装的程序的 --version 输出中。例如，–with-pkgversion=‘FooBar GNU/Linux glibc build 123’。默认值为“GNU libc”。

‘–with-bugurl=url’
指定用户在报告错误时应访问的 URL，该 URL 将包含在随 GNU C 库安装的程序的 --help 输出中。默认值是指 GNU C 库的主要错误报告信息。

要构建库和相关程序，请键入 make。这将产生大量输出，其中一些可能看起来像 make 的错误，但不是。从 make 中查找包含“***”的错误消息。这些表明某些事情是严重错误的。

编译过程可能需要很长时间，具体取决于您机器的配置和速度。一些复杂的模块可能需要很长时间才能编译，在较慢的机器上可能需要几分钟。如果编译器似乎挂起，请不要惊慌。

如果要运行并行 make，只需传递带有适当数字参数的“-j”选项即可。不过，您需要一个最新的 GNU make 版本。

要构建和运行使用某些库设施的测试程序，请键入 make check。如果没有成功完成，请不要使用构建的库，并在验证问题未知后报告错误。有关报告错误的说明，请参阅报告错误。请注意，某些测试假定它们不是由 root 运行的。我们建议您以非特权用户的身份编译和测试 GNU C 库。

在报告错误之前，请确保您的系统没有问题。测试（以及以后的安装）使用系统的一些预先存在的文件，例如 /etc/passwd、/etc/nsswitch.conf 和其他文件。这些文件必须都包含正确和合理的内容。

通常，make check 会在报告发现的所有问题之前运行所有测试，如果发生任何问题，则以错误状态退出。您可以在运行 make check 时指定 ‘stop-on-test-failure=y’ 以使测试运行在发生故障时立即停止并以错误状态退出。

要格式化 GNU C 库参考手册以进行打印，请键入 make dvi。您需要一个有效的 TeX 安装来执行此 *** 作。该发行版将手册的在线格式版本构建为信息文件，作为构建过程的一部分。您可以使用 make info 手动构建它们。

该库有许多特殊用途的配置参数，您可以在 Makeconfig 中找到它们。这些可以用文件 configparms 覆盖。要更改它们，请在构建目录中创建一个 configparms 并添加适合您系统的值。该文件由 make 包含和解析，并且必须遵循 makefile 的约定。

通过在 configparms 中设置一些变量，很容易配置 GNU C 库以进行交叉编译。将 CC 设置为您为其配置库的目标的交叉编译器；在运行 configure 时使用相同的 CC 值很重要，例如：‘configure target CC=target-gcc’。将 BUILD_CC 设置为编译器以用于在编译系统上运行的程序作为编译库的一部分。如果本机工具未配置为使用您配置的目标的目标文件，您可能需要将 AR 设置为 ar 的交叉编译版本。交叉编译 GNU C 库时，可以使用 ‘make check test-wrapper=“srcdir/scripts/cross-test-ssh.sh hostname”’ 对其进行测试，其中 srcdir 是主源目录的绝对目录名，hostname 是可以运行 GNU C 库的新构建二进制文件的系统的主机名。源目录和构建目录必须在构建系统和主机名的相同位置可见。当设置了 glibc_test_allow_time_setting 环境变量时，‘cross-test-ssh.sh’脚本需要‘util-linux’中的‘flock’才能工作。

也可以执行测试，这需要在目标机器上设置日期。支持以下用例：

• GLIBC_TEST_ALLOW_TIME_SETTING 在执行合格测试并有权运行clock_settime 的环境中设置。在这种情况下，没有什么可以阻止这些测试并行运行，因此调用者应确保这些测试已序列化或为它们提供适当的包装脚本。
• 使用 cross-test-ssh.sh 脚本并通过 --allow-time-setting 标志。在这种情况下，两个集合 GLIBC_TEST_ALLOW_TIME_SETTING 和测试执行的序列化都是自动保证的。

通常，在测试 GNU C 库时，可以将“test-wrapper”设置为任何程序的名称和参数以运行新构建的二进制文件。该程序必须保留正在运行的二进制文件的参数、其工作目录以及标准输入、输出和错误文件描述符。如果“test-wrapper env”无法运行设置了环境变量的程序，那么“test-wrapper-env”必须设置为运行新建程序且环境变量分配有效的程序，这些分配被指定作为要运行的程序名称之前的 ‘var=value’。如果指定了对同一变量的多个赋值，则指定的最后一个赋值必须优先。类似地，如果“test-wrapper env -i”不能运行一个环境完全没有变量的程序，除了直接分配的变量，那么必须设置“test-wrapper-env-only”；它的使用与“test-wrapper-env”具有相同的语法，其语义上的唯一区别是从一组空的环境变量而不是环境变量开始。

对于带有 SVE 的 AArch64，在测试 GNU C 库时，可以将“test-wrapper”设置为“srcdir/sysdeps/unix/sysv/linux/aarch64/vltest.py vector-length”以更改向量长度。

2.2. 安装 C 库

Installing the C Library

要安装库及其头文件以及手册的 Info 文件，请键入 make install。如有必要，这将在安装之前构建东西；但是，您仍然应该先编译所有内容。如果您将 GNU C 库安装为您的主要 C 库，我们建议您先将系统关闭到单用户模式，然后再重新启动。当库从下面更改时，这可以最大限度地减少破坏事物的风险。

‘make install’ 将完成从先前安装的 GNU C 库 2.x 版升级的全部工作。有时可能会留下以前安装的标头，但这些通常是无害的。如果您想避免留下标题，您可以按以下顺序执行 *** 作。

您必须首先构建库（“make”），可选地检查它（“make check”），切换包含目录，然后安装（“make install”）。这些步骤必须按此顺序完成。在安装之前不移动目录将导致两个库中的头文件混合在一起无法使用，但是配置、构建和检查库需要能够针对旧库编译和运行程序。新的 /usr/include，在切换包含目录之后和安装库之前应该包含 Linux 头文件，但没有其他内容。如果这样做，您将需要在安装库后自己从 GNU C 库以外的库中恢复任何头文件。

您可以通过在命令行上为“make install”设置 DESTDIR GNU 标准 make 变量来将 GNU C 库安装到您配置它的位置以外的地方。此变量的值会附加到所有安装路径。这在设置 chroot 环境或准备二进制分发时很有用。应使用绝对文件名指定目录。不支持使用前缀和 exec_prefix GNU 标准 make 变量集进行安装。

GNU C 库包含一个名为 nscd 的守护进程，您可能希望也可能不想运行它。nscd 缓存名称服务查找；它可以显着提高 NIS+ 的性能，也可能有助于 DNS。

如果使用了“–enable-pt_chown”配置选项，则会安装一个辅助程序 /usr/libexec/pt_chown，setuid root。该程序由 grantpt 函数调用；它在伪终端上设置权限，以便调用进程可以使用它。如果您使用的是启用了 devpts 文件系统并安装在 /dev/pts 的 Linux 内核，则不需要此程序。

安装后，您应该配置时区并为您的系统安装语言环境。时区配置可确保您的系统时间与您当前时区的时间相匹配。语言环境确保系统上的信息显示符合您的语言和地理区域的期望。

GNU C 库能够使用两种本地化信息源，第一种是名为 locale-archive 的语言环境数据库，它通常安装为 /usr/lib/locale/locale-archive。语言环境存档的好处是占用空间更少并且加载速度非常快，但前提是您计划安装 60 个或更多语言环境。如果您计划安装一个或两个语言环境，您可以将各个语言环境安装到它们的同名目录中，例如/usr/lib/locale/en_US.utf8。例如，要使用名称为 de_DE 的 UTF-8 字符集将德语语言环境安装到语言环境存档中，请发出命令“localedef -i de_DE -f UTF-8 de_DE”，并只安装一个语言环境，发出命令“localedef” --no-archive -i de_DE -f UTF-8 de_DE’。要配置 GNU C 库支持的所有语言环境，您可以从构建目录发出命令 ‘make localedata/install-locales’ 将所有语言环境安装到语言环境存档中，或者使用 ‘make localedata/install-locale-files’ 来将所有语言环境作为文件安装在默认配置的语言环境安装目录中（派生自“–prefix”或–localedir）。要安装到备用系统根目录，请使用“DESTDIR”，例如‘make localedata/install-locale-files DESTDIR=/opt/glibc’，但请注意，这不会更改配置的前缀。

要配置本地使用的时区，请设置 TZ 环境变量。脚本 tzselect 可帮助您选择正确的值。例如，对于德国，tzselect 会告诉您使用“TZ=‘Europe/Berlin’”。对于系统范围的安装（给定的路径适用于使用“–prefix=/usr”的安装），将 /usr/share/zoneinfo 中的时区文件链接到文件 /etc/localtime。对于德国，您可以执行“ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime”。

2.3. 推荐的编译工具

Recommended Tools for Compilation

我们建议在尝试构建 GNU C 库之前安装以下 GNU 工具：

• GNU make 4.0 或更新版本

  截至发布时，GNU make 4.3 是最新的经验证可用于构建 GNU C 库的版本。

• GCC 6.2 或更新版本

  需要 GCC 6.2 或更高版本。一般来说，建议使用已知可用于构建 GNU C 库的最新版本的编译器，因为较新的编译器通常会生成更好的代码。截至发布时，GCC 12.0 是经过验证可用于构建 GNU C 库的最新编译器。

  对于 PowerPC 64 位 little-endian (powerpc64le)，需要支持 -mno-gnu-attribute、-mabi=ieeelongdouble 和 -mabi=ibmlondouble 的 GCC 版本。同样，编译器还必须支持使用前面的选项传递 -mlong-double-128。在发布时，这意味着 GCC 7.4 和更新版本（GCC 7.5.0 除外，请参阅 GCC PR94200）。这些附加功能是构建支持 IEEE long double 的 GNU C 库所必需的。

  对于 ARC 架构构建，需要 GCC 8.3 或更高版本。

  对于 s390x 架构构建，需要 GCC 7.1 或更高版本（请参阅 gcc 错误 98269）。

  对于多架构支持，建议使用支持 GNU 间接函数的 GCC。这可确保为 IFUNC 解析器选择的函数生成正确的调试信息。可以通过使用“–enable-gnu-indirect-function”配置 GCC 来启用此支持，或者通过在 GCC 源文件 gcc/config.gcc 中为特定架构设置“default_gnu_indirect_function”变量来默认启用它。

  您可以使用任何您喜欢的编译器来编译使用 GNU C 库的程序。

  查看常见问题解答，了解特定平台上的任何特殊编译器问题。

• GNU binutils 2.25 或更高版本

  您必须使用 GNU binutils（as 和 ld）来构建 GNU C 库。目前没有其他汇编器或链接器具有必要的功能。截至发布时，GNU binutils 2.37 是最新的经验证可用于构建 GNU C 库的版本。

  对于 PowerPC 64 位 little-endian (powerpc64le)，需要 objcopy 来支持 --update-section。此选项需要 binutils 2.26 或更高版本。

  ARC 架构需要 binutils 2.32 或更高版本才能进行 TLS 相关修复。

• GNU texinfo 4.7 或更高版本

  要正确翻译和安装 Texinfo 文档，您需要此版本的 texinfo 包。早期版本不理解文档中使用的所有标签，并且信息文件的安装机制不存在或工作方式不同。截至发布时，texinfo 6.8 是最新的经验证可用于构建 GNU C 库的版本。

• GNU awk 3.1.2 或更高版本

  awk 在多个地方用于生成文件。使用了一些 gawk 扩展，包括在 gawk 版本 3.1.2 中引入的 asorti 函数。截至发布时，gawk 版本 5.1.1 是经过验证可用于构建 GNU C 库的最新版本。

• GNU bison 2.7 或更高版本

  bison 用于在 intl 子目录中生成 yacc 解析器代码。截至发布时，bison 版本 3.8.2 是经过验证可用于构建 GNU C 库的最新版本。

• Perl 5

  Perl 不是必需的，但如果存在的话，它会在某些测试和 mtrace 程序中使用，以构建 GNU C 库手册。截至发布时，perl 版本 5.34.0 是经过验证可用于构建 GNU C 库的最新版本。

• GNU sed 3.02 或更新版本

  Sed 在多个地方用于生成文件。大多数脚本适用于任何版本的 sed。截至发布时，sed 4.8 版是经过验证的最新版本，可用于构建 GNU C 库。

• Python 3.4 或更高版本

  Python 是构建 GNU C 库所必需的。截至发布时，Python 3.10.2 是最新的经过验证可用于构建和测试 GNU C 库的版本。

• PExpect 4.0

  漂亮的打印机测试通过测试程序驱动 GDB，并将其输出与打印机的输出进行比较。PExpect 用于捕获 GDB 的输出，并且应该与您系统中的 Python 版本兼容。截至发布时，PExpect 4.8.0 是经过验证的最新版本，可用于测试漂亮的打印机。

• GDB 7.8 或更高版本，支持 Python 2.7/3.4 或更高版本

  GDB 本身需要配置 Python 支持才能使用漂亮的打印机。请注意，您的系统有 Python 可用并不意味着 GDB 支持它，也不意味着您系统的 Python 和 GDB 具有相同的版本。截至发布时，GNU 调试器 11.1 是经过验证的最新版本，可用于测试漂亮的打印机。

  除非存在支持 Python 的 Python、PExpect 和 GDB，否则打印机测试将报告自己为 UNSUPPORTED。请注意，某些打印机测试需要使用调试符号编译 GNU C 库。

如果您更改任何 configure.ac 文件，您还需要

• GNU autoconf 2.69（完全正确）

如果您更改任何消息翻译文件，您将需要

• GNU gettext 0.10.36 或更高版本

  截至发布时，GNU gettext 0.21 版是经过验证可用于构建 GNU C 库的最新版本。

如果您使用补丁升级源代码树，您可能还需要这些软件包，尽管我们会尽量避免这种情况。

2.4. 针对 GNU/Linux 系统的具体建议

Specific advice for GNU/Linux systems

如果您在 GNU/Linux 系统上安装 GNU C 库，则需要有 3.2 或更新内核的头文件以供参考。（对于 ia64 架构，您需要 3.2.18 或更高版本，因为这是第一个支持 accept4 系统调用的版本。）这些头文件必须使用“make headers_install”安装；内核源代码目录中的头文件不适合 GNU C 库直接使用。您不需要使用该内核，只需将其头文件安装在 GNU C 库可以访问它们的位置，这里称为安装目录。最简单的方法是将其解压缩到 /usr/src/linux-version 等目录中。在该目录中，运行“make headers_install INSTALL_HDR_PATH=install-directory”。最后，使用选项“–with-headers=install-directory/include”配置 GNU C 库。使用您可以获得的最新内核。（如果是交叉编译 GNU C 库，需要在 ‘make headers_install’ 命令中指定 ‘ARCH=architecture’，其中 architecture 是 Linux 内核使用的架构名称，例如 ‘x86’ 或 ‘powerpc’ .)

安装 GNU C 库后，您可能需要删除或重命名目录，例如 /usr/include/linux 和 /usr/include/asm，并用 install-directory/include 中的 linux 和 asm 等目录的副本替换它们。应该复制 install-directory/include 中的所有目录，但 GNU C 库提供了自己的 /usr/include/scsi 版本；内核提供的文件应该被复制而不替换 GNU C 库提供的文件。使用 GNU C 库编译程序需要 linux、asm 和 asm-generic 目录；其他目录描述内核的接口，但如果不使用这些接口编译程序则不需要。如果您没有使用“–with-headers”指定备用内核标头源，则不需要复制内核标头。

GNU/Linux 系统的文件系统层次标准要求 GNU C 库安装的某些组件位于 /lib 中，而某些位于 /usr/lib 中。如果您使用“–prefix=/usr”配置 GNU C 库，这将自动处理。如果您设置一些其他前缀或允许它默认为 /usr/local，那么所有组件都安装在那里。

截至发布时，Linux 5.16 版是经过验证可用于构建 GNU C 库的最新版本。

2.5. 报告错误

Reporting Bugs

GNU C 库中可能存在错误。本手册中肯定存在错误和遗漏。如果您报告它们，它们将得到修复。如果你不这样做，没有人会知道它们，它们将永远保持不变，如果不是更长的话。

最好验证该问题尚未报告。错误记录在两个地方：文件 BUGS 描述了许多众所周知的错误，中央 GNU C 库错误跟踪系统在 https://sourceware.org/bugzilla/ 上有一个 WWW 界面。WWW 界面使您可以访问打开和关闭的报告。封闭的报告通常包括解决问题的补丁或提示。

要报告错误，首先您必须找到它。运气好的话，这将是最困难的部分。一旦你发现了一个错误，请确保它确实是一个错误。这样做的一个好方法是查看 GNU C 库的行为是否与其他 C 库的行为相同。如果是这样，可能你错了，图书馆是对的（但不一定）。如果不是，则其中一个库可能是错误的。它可能不是 GNU C 库。许多历史上的 Unix C 库允许我们不允许的事情，例如关闭文件两次。

如果您认为您发现了 GNU C 库不符合 ISO 和 POSIX 标准的某种方式（请参阅标准和可移植性），那绝对是一个错误。举报！

一旦你确定你找到了一个错误，试着把它缩小到重现问题的最小测试用例。对于 C 库，如果可能的话，您实际上只需要将其缩小到一个库函数调用。这应该不会太难。

当你有一个简单的测试用例时，最后一步是报告错误。在 https://www.gnu.org/software/libc/bugs.html 执行此 *** 作。

如果你不确定一个函数应该如何表现，而本手册没有告诉你，那是手册中的一个错误。也举报！如果函数的行为与手册不一致，则说明库或手册存在错误，因此请报告分歧。如果您在本手册中发现任何错误或遗漏，请向错误数据库报告。如果您参考手册的特定章节，请包括章节名称以便于识别。

3. 参考

• Appendix C Installing the GNU C Library