开发人员指南

先决条件

可能的代码表单

使用 C 和 C++ 语言时，有三种类型的代码：

在 GCC 中处理代码表单

从源代码生成可执行代码需要两个步骤，它们需要不同的应用程序或工具。GCC 可用作编译器和链路器的智能驱动程序。这可让您对任何所需操作使用单个命令 gcc。GCC 自动选择所需操作（编译和链接），以及它们的顺序：

可以运行 GCC 以便只发生第 1 步、只发生第 2 步或执行第 1 步和第 2 步。这由输入类型和请求的输出类型决定。

因为大型项目需要一个构建系统，它通常会为每个操作单独运行 GCC，因此始终将编译和链接视为两个不同的操作，即使 GCC 可以同时执行。

其它资源

要从源代码文件而不是可执行文件立即创建对象代码文件，必须指示 GCC 仅创建对象代码文件作为其输出。此操作代表了大型项目的构建流程的基本操作。

先决条件

步骤

其它资源

由于调试信息较大，因此默认情况下，不会包含在可执行文件中。要为您的 C 和 C++ 应用程序进行调试，您必须明确指示编译器创建调试信息。

使用 GCC 启用调试信息

要在编译和链接代码时使用 GCC 创建调试信息，请使用 -g 选项：

gcc ... -g ...

$ gcc ... -g ...

其它资源

单个程序可以转换为多个计算机指令序列。如果为编译期间为分析代码分配了更多资源，则可以实现最佳结果。

使用 GCC 进行代码优化

在 GCC 中，可以使用 -O级别 选项来设置优化级别。这个选项接受一组值来代替 级别。

对于版本构建，建议使用优化选项 -O2。

在开发过程中，-Og 选项在某些情况下用于调试程序或库。因为有些错误清单只具有某些优化级别，所以请确保使用发行版本优化级别测试程序或库。

GCC 提供了大量选项，以实现单个优化。如需更多信息，请参阅以下附加资源。

其它资源

当编译器将源代码转换为对象代码时，它可以添加各种检查来防止经常被利用的情况，从而提高安全性。选择正确的编译器选项集可帮助生成更安全的程序和库，而无需更改源代码。

发行版本选项

对于目标为 Red Hat Enterprise Linux 的开发人员，推荐使用以下选项列表：

gcc ... -O2 -g -Wall -Wl,-z,now,-z,relro -fstack-protector-strong -D_FORTIFY_SOURCE=2 ...

$ gcc ... -O2 -g -Wall -Wl,-z,now,-z,relro -fstack-protector-strong -D_FORTIFY_SOURCE=2 ...

开发选项

建议您在开发过程中检测安全漏洞。使用这些选项以及发行版本的选项：

gcc ... -Walloc-zero -Walloca-larger-than -Wextra -Wformat-security -Wvla-larger-than ...

$ gcc ... -Walloc-zero -Walloca-larger-than -Wextra -Wformat-security -Wvla-larger-than ...

其它资源

构建 C 或 C++ 应用程序时，链接是最后一步。链接将所有对象文件和库组合到一个可执行文件中。

先决条件

步骤

其它资源

红帽生态系统包括多个 Red Hat Enterprise Linux 和 Red Hat Developer Toolset 提供的 GCC 编译器和 linker 版本。两者之间的 C++ ABI 兼容性如下：

其它资源

此示例显示构建最小 C 程序示例的具体步骤。

先决条件

步骤

其它资源

本例显示了构建最小 C++ 程序的具体步骤。

先决条件

步骤

特殊文件名规则用于库：名为 foo 的库应该作为文件 libfoo.so 或 libfoo.a 存在。这个约定由 gcc 的链接输入选项自动理解，但输出选项并不包括：

其它资源

开发人员可以选择使用完全编译的语言构建应用程序时使用静态或动态链接。这部分列出了区别，特别是在 Red Hat Enterprise Linux 中使用 C 和 C++ 语言的情况。总之，红帽不建议在 Red Hat Enterprise Linux 的应用程序中使用静态链接。

静态和动态链接的比较

静态链接使库成为生成的可执行文件的一部分。动态链接将这些库保留为单独的文件。

可以通过多种方式比较动态和静态链接：

由于列出的缺点，应不加成本避免静态链接，特别是整个应用程序和 glibc 和 libstdc++ 库。

静态链路的原因

静态链接在某些情况下可能是合理的选择，例如：

其它资源

库是可在您的程序中重复使用的代码软件包。C 或 C++ 库由两个部分组成：

使用库编译代码

标头文件描述库的接口：库中提供的函数和变量。编译代码需要标题文件中的信息。

通常，库的标题文件将放置在与您的应用代码不同的目录中。要告诉 GCC 标头文件的位置，请使用 -I 选项：

gcc ... -Iinclude_path ...

$ gcc ... -Iinclude_path ...

使用标头文件目录的实际路径替换 include_path。

I 选项可 多次使用，以添加包含标题文件的多个目录。查找标头文件时，会在 -I 选项中按照其外观的顺序搜索这些目录。

使用库链接代码

当链接可执行文件时，您的应用程序对象代码和库的二进制代码都必须可用。静态和动态库的代码以不同的格式显示：

要告诉 GCC 库的存档或共享对象文件的位置，请使用 -L 选项：

gcc ... -Llibrary_path -lfoo ...

$ gcc ... -Llibrary_path -lfoo ...

使用库目录的实际路径替换 library_path。

L 选项可 多次使用，以添加多个目录。查找库时，系统将按照其 -L 选项的顺序搜索这些目录。

选项顺序很重要：GCC 无法链接到库 foo，除非它知道这个库的目录。因此，使用 -L 选项来指定库目录，然后再使用 -l 选项链接到库。

在同一步骤中编译和链接代码使用库

当一个 gcc 命令中允许编译并链接代码时，请一次性对上述两种情况使用 选项。

其它资源

静态库可用作包含对象文件的存档。链接后，它们将成为生成的可执行文件的一部分。

先决条件

步骤

要从源和对象文件中链接程序，请添加静态链接库 foo，名为 libfoo.a ：

动态库以独立可执行文件的形式提供，在链接时间和运行时都是必需的。它们与您的应用程序的可执行文件保持独立。

先决条件

链接程序 Against 是一个动态库

根据动态库 foo 关联程序：

gcc ... -Llibrary_path -lfoo ...

$ gcc ... -Llibrary_path -lfoo ...

当程序与动态库链接时，生成的程序必须在运行时始终加载库。查找库有两个选项：

使用存储在可执行文件中的 rpath 值

rpath 是一个特殊值，在链接文件时保存为可执行文件的一部分。之后，从可执行文件加载程序时，运行时链接器将使用 rpath 值来查找库文件。

使用 GCC 链接时，将路径 library_path 保存为 rpath ：

gcc ... -Llibrary_path -lfoo -Wl,-rpath=library_path ...

$ gcc ... -Llibrary_path -lfoo -Wl,-rpath=library_path ...

路径 library_path 必须指向包含文件 libfoo.so 的目录。

要稍后运行程序，请执行：

./program

$ ./program

使用 LD_LIBRARY_PATH 环境变量

如果在程序的可执行文件中没有找到 rpath，则运行时链接器将使用 LD_LIBRARY_PATH 环境变量。必须根据共享库对象所在路径更改每个程序的值。

要运行没有设置 rpath 的程序，且 library_path 中存在库，请执行：

export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH
./program

$ export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH
$ ./program

省略 rpath 值可提供灵活性，但每次程序运行时，需要设置 LD_LIBRARY_PATH 变量。

将库放入默认目录

运行时链接器配置指定多个目录作为动态库文件的默认位置。要使用此默认情况，请将您的库复制到适当的目录中。

有关动态链路器行为的完整描述超出了本文档的范围。如需更多信息，请参阅以下资源：

有时需要静态地和某些库动态链接一些库。

先决条件

简介

GCC 识别 动态和静态库。遇到 -lfoo 选项后，gcc 将首先尝试查找包含 foo 库动态链接版本的共享对象（a .so 文件），然后查找包含库静态版本的存档文件(.a)。因此，这个搜索可能会导致以下情况：

由于这些规则，选择用于链接的库的静态或动态版本的最佳方法是仅让 gcc 找到该版本。在指定 -L 路径选项时，可以使用 或在指定 -L路径选项时保留包含库版本的目录，以控制 这一点。

此外，由于动态链接是默认的，因此必须明确指定链接的唯一情况是当一个存在两个版本的库都应静态链接。有两种可能的解决方案：

通过文件指定静态库

通常，使用 -l foo 选项指示 gcc 与库foo链接。但是，可以指定到文件 libfoo.a.a 包含库的完整路径：

gcc ... path/to/libfoo.a ...

$ gcc ... path/to/libfoo.a ...

从文件 extension .a，gcc 将理解这是一个与程序链接的库。但是，指定库文件的完整路径是一个不太灵活的方法。

使用 -Wl 选项

gcc 选项 -Wl 是将选项传递给底层链接器的特殊选项。此选项的语法与其他 gcc 选项不同。Wl 选项加上以逗号分隔的 linker 选项列表，而其他 gcc 选项则需要以空格分隔的选项列表。gcc 使用的 ld linker 提供 -Bstatic 和 -Bdynamic 选项，以指定以下这个选项是否应分别链接或动态链接。将 -Bstatic 和库传递给 linker 后，默认的动态链接行为必须手动恢复，才能使以下库与 -Bdynamic 选项动态链接动态链接动态链接。

要链接程序，请运行以静态方式链接库(lib first.a)和 第二个 动态(libsecond.so)，请运行：

gcc ... -Wl,-Bstatic -lfirst -Wl,-Bdynamic -lsecond ...

$ gcc ... -Wl,-Bstatic -lfirst -Wl,-Bdynamic -lsecond ...

其它资源

特殊文件名规则用于库：名为 foo 的库应该作为文件 libfoo.so 或 libfoo.a 存在。这个约定由 gcc 的链接输入选项自动理解，但输出选项并不包括：

其它资源

动态加载的库（共享对象）使用名为 soname 的机制来管理库的多个兼容版本。

先决条件

问题简介

动态加载的库（共享对象）作为一个独立的可执行文件存在。这样便可在不更新依赖于它的应用程序的情况下更新库。但是，这个概念会出现以下问题：

soname Mechanism

为了解决这个问题，Linux 使用一种称为 soname 的机制。

库 foo 版本 X.Y 与其它版本兼容，与版本号中的 X 值相同。保持兼容性的小更改会增加数字 Y。破坏兼容性的主要变化会增加 X。

实际库 foo 版本 X.Y 作为文件 libfoo.so.x 存在。y.在库文件中，记录了一个 soname，值为 libfoo.so.x 以表示兼容性。

构建应用程序时，链接器通过搜索文件 libfoo.so 来查找库。必须存在具有此名称的符号链接，指向实际库文件。然后，链接器从库文件中读取 soname，并将其记录到应用程序可执行文件中。最后，linker 创建应用程序，以便使用 soname 而不是名称或文件名来声明对库的依赖项。

当运行时的动态链路器在运行前链接应用程序时，它会从应用程序的可执行文件中读取 soname。该 soname 是 libfoo.so.x。必须存在具有此名称的符号链接，指向实际库文件。无论版本的 Y 组件是什么，都允许载入库，因为 soname 不会改变。

从文件中读取 soname

显示库文件 somelibrary 的 soname：

objdump -p somelibrary | grep SONAME

$ objdump -p somelibrary | grep SONAME

使用您要检查的库的实际文件名替换 somelibrary。

通过更轻松地更新库代码，动态链接的库（共享对象）允许通过代码重复使用和增强安全性。这部分论述了从源构建和安装动态库的步骤。

先决条件

步骤

其它资源

通过将对象文件转换为特殊类型的存档文件，可以创建用于静态链接的库。

先决条件

步骤

其它资源

要从特定项目的源文件创建可用的表单（通常是可执行文件），请执行几个必要的步骤。记录操作及其顺序，以便稍后重复操作。

Red Hat Enterprise Linux 包含 GNU make，这是专为此目的设计的构建系统。

先决条件

GNU make

GNU make 读取 Makefile，其中包含描述构建过程的说明。Makefile 包含多个 规则，它们描述通过特定操作（方法）满足特定条件（目标）的方式。规则可以分层依赖于另一条规则。

运行不带任何选项的 make 即可在当前目录中查找 Makefile 并尝试访问默认目标。实际的 Makefile 文件名可以是 Makefile、makefile 和 GNUmakefile 之一。默认目标由 Makefile 内容决定。

Makefile 详情

makefile 使用相对简单的语法来定义 变量 和 规则,这些变量和规则由一个 target 和一个 recipe 组成。如果执行规则，则目标指定输出。具有配方的行必须以 tab 字符开头。

通常，Makefile 包含用于编译源文件的规则、用于链接结果对象文件的规则，以及充当层次结构顶部的入口点的目标。

请考虑以下 Makefile 用于构建由单个文件 hello.c 组成的 C 程序。

all: hello

hello: hello.o
        gcc hello.o -o hello

hello.o: hello.c
        gcc -c hello.c -o hello.o

all: hello

hello: hello.o
        gcc hello.o -o hello

hello.o: hello.c
        gcc -c hello.c -o hello.o

这将指定，要访问 所有目标，需要 hello 文件。要获得 hello，您需要 hello.o （由 gcc 链接），后者从 hello.c 创建（由 gcc编译）。

目标 all 是默认目标，因为它是不是以句点开头的第一个目标。如果当前目录包含这个 Makefile，则不带任何参数运行 make 会完全运行 make。

典型的 Makefile

较典型的 Makefile 使用变量来常规调整步骤，并添加目标"clean"，这将删除除源文件以外的所有对象。

CC=gcc
CFLAGS=-c -Wall
SOURCE=hello.c
OBJ=$(SOURCE:.c=.o)
EXE=hello

all: $(SOURCE) $(EXE)

$(EXE): $(OBJ)
        $(CC) $(OBJ) -o $@

%.o: %.c
        $(CC) $(CFLAGS) $< -o $@

clean:
        rm -rf $(OBJ) $(EXE)

CC=gcc
CFLAGS=-c -Wall
SOURCE=hello.c
OBJ=$(SOURCE:.c=.o)
EXE=hello

all: $(SOURCE) $(EXE)

$(EXE): $(OBJ)
        $(CC) $(OBJ) -o $@

%.o: %.c
        $(CC) $(CFLAGS) $< -o $@

clean:
        rm -rf $(OBJ) $(EXE)

向此类 Makefile 添加更多源文件需要将它们添加到定义 SOURCE 变量的行。

其他资源

按照以下示例中的步骤，使用 Makefile 来构建示例 C 程序。

先决条件

步骤

其它资源

有关 make 的更多信息，请参阅以下列出的资源。

安装的文档

在线文档

要调试应用和库，需要调试信息。以下小节描述了如何获取此信息。

gcc ... -g ...

$ gcc ... -g ...

若要找出应用无法正常工作的原因，请控制其执行并使用调试器检查其内部状态。本节论述了如何将 GNU Debugger(GDB)用于此任务。

gdb program

$ gdb program

(gdb) file path/to/program

(gdb) file path/to/program

应用程序的可执行代码与操作系统和共享库的代码交互。记录这些交互的活动日志可在不调试实际应用程序代码的情况下充分洞察应用的行为。另外，分析应用程序的交互可帮助确定存在错误清单的条件。

ltrace ... |& tee your_log_file.log

$ ltrace ... |& tee your_log_file.log

这部分论述了 内核转储 是什么以及如何使用它。

先决条件

描述

在应用程序停止工作时，核心转储是部分应用程序内存的副本，以 ELF 格式存储。它包含应用的所有内部变量和堆栈，可以检查应用的最终状态。使用相应的可执行文件和调试信息进行增强时，可以使用调试器以类似于分析正在运行的程序的方式分析核心转储文件。

如果启用了此功能，Linux 操作系统内核会自动记录内核转储。或者，您可以向任何正在运行的应用发送信号，以生成核心转储，而不考虑其实际状态。

要记录应用程序崩溃，请设置核心转储保存并添加系统信息。

步骤

其它资源

先决条件

步骤

其它资源

内核转储调试的工作流允许分析程序的离线状态。在某些情况下，将这个工作流与仍在运行的程序配合使用时很有用，例如难以使用该进程访问环境时。您可以使用 gcore 命令转储仍在运行的任何进程的内存。

先决条件

步骤

使用 gcore 转储进程内存：

其他资源

您可以将进程内存标记为不会转储。这可节省资源并确保进程内存包含敏感数据，以确保其他安全性。内核内核转储(kdump)和手动内核转储(gcore，GDB)都不会转储以这种方式标记的内存。

在某些情况下，无论这些保护是什么，都需要转储进程内存的所有内容。此流程演示了如何使用 GDB 调试器执行此操作。

先决条件

步骤

其它资源

Valgrind 套件由以下工具组成：

在未选择特定工具时，Mer Memcheck 函数作为默认工具。

valgrind 软件包及其依赖项安装执行 Valgrind 配置集运行的所有必要工具。要对带有 Valgrind 的程序进行性能分析，请使用：

valgrind --tool=toolname program

$ valgrind --tool=toolname programvalgrind --tool=toolname programvalgrind --tool=toolname programvalgrind --tool=toolname program

有关 工具 名称 的参数列表，请参阅 第 22.1 节 “Valgrind 工具”。除了 Valgrind 工具套件外，无 也是工具名称的有效参数；此参数允许您在 Valgrind 下运行程序，而无需执行任何性能分析。 这可用于调试或基准测试 Valgrind 本身。

您还可以指示 Valgrind 将所有信息发送到特定文件。为此，请使用选项 --log-file=filename。例如，要检查可执行文件 hello 的内存用量并将配置集信息发送到 输出，请使用：

valgrind --tool=memcheck --log-file=output hello

$ valgrind --tool=memcheck --log-file=output hello

有关 Valgrind 的更多信息，以及 Valgrind 工具套件的其它可用文档，请参阅 第 22.3 节 “其他信息”。

有关 Valgrind 的更多信息，请参阅 man valgrind。Red Hat Enterprise Linux 还提供 PDF 和 HTML 中的综合 Valgrind 文档 一书：