在 RHEL 8 中开发 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 ...

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

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

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

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

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

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

选项的顺序很重要：GCC 不能链接库 foo，除非其知道此库的目录。因此，在使用 -l 选项链接库之前，请使用 -L 选项来指定库目录。

静态库作为包含目标文件的存档提供。链接后，它们成为生成的可执行文件的一部分。

动态库作为独立的可执行文件提供，在链接时和运行时需要。它们独立于您应用程序的可执行文件。

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

当程序链接了动态库时，生成的程序必须总是在运行时加载库。定位库有两个选项：

与 GCC 链接时，要将路径 library_path 存储为 rpath ：

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

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

要稍后运行程序：

$ ./program

要运行没有 rpath 设置的程序，库要存在于路径 library_path 中：

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

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

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

有时需要静态链接一些库，有时需要动态链接一些库。这种情况带来了一些挑战。

由于这些规则，选择用于链接的库的静态或动态版本的最佳方法是让 gcc 只找到该版本。在指定 -Lpath 选项时，可以使用或省略包含库版本的目录，来在某种程度上控制它。

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

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

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

gcc 使用的 ld 链接器提供选项 -Bstatic 和 -Bdynamic，来指定此选项后面的库是否应分别被静态链接或动态链接。在将 -Bstatic 和库传给链路器后，必须为以下使用 -Bdynamic 选项动态链接的库手动恢复默认的动态链接行为：

要链接程序，请静态链接库first (libfirst.a)，动态链接库second (libsecond.so)：

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

对库使用特殊文件名惯例：名为 foo 的库应该以文件 libfoo.so 或 libfoo.a 的形式存在。通过链接 GCC 的输入选项（而非输出选项）可自动理解这一惯例：

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

foo 库版本 X.Y 与版本号为 X 的其他版本 ABI 兼容。保持兼容性的次更改会增加数字 Y。破坏兼容性的主更改会增加数字 X。

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

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

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

$ objdump -p somelibrary | grep SONAME

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

动态链接的库（共享目标）允许：

按照以下步骤从源构建和安装动态库。

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

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

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

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

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

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

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.c 创建的（由 gcc编译）。

目标 all 是默认目标，因为它是不是以句点(.)开头的第一个目标。当当前目录包含这个 Makefile 时，运行不带任何参数的 make 与运行 make all 一样。

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 的更多信息，请参阅以下列出的资源。

在 Red Hat Enterprise Linux 8 中，GCC 工具链基于 GCC 8.2 发行系列。从 Red Hat Enterprise Linux 7 开始的显著变化包括：

如需了解更多详细信息，请参阅 第 2.5.2 节 “RHEL 8 中 GCC 的安全性增强”。

以下是与 Red Hat Enterprise Linux 7.0 发布以来与安全性相关的 GCC 的更改。

std::string 和 std::list 中 C++ ABI 的更改

std::string 的应用程序二进制接口(ABI)和 libstdc++ 库中的std::list 类在 RHEL 7(GCC 4.8)和 RHEL 8(GCC 8)之间的变化符合 C++11 标准。libstdc++ 库同时支持旧的和新的 ABI，但些其他一些 C++ 系统库不支持。因此，动态链接这些库的应用程序需要重建。这会影响所有 C++ 标准模式，包括 C++98。它还影响了使用 RHEL 7 的 Red Hat Developer Toolset 编译器构建的应用程序，这些应用程序保留了旧的 ABI，以保持与系统库的兼容性。

GCC 不再构建 Ada、Go 和 Objective C/C++ 代码

在 Ada(GNAT)、GCC Go 和目标 C/C++ 语言中构建代码的能力已从 GCC 编译器中删除。

要构建 Go 代码，请使用 Go Toolset。

在调试任何可执行代码时，两种类型的信息允许程序员通过工具和扩展来理解二进制代码：

此类信息称为调试信息。

Red Hat Enterprise Linux 对可执行二进制文件、共享库或 debuginfo 文件使用 ELF 格式。在这些 ELF 文件中，DWARF 格式用于保存调试信息。

要显示存储在 ELF 文件中的 DWARF 信息，请运行 readelf -w file 命令。

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

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

$ gcc ... -g ...

debuginfo 和 debugsource 软件包包含程序和库的调试信息和调试源代码。对于安装在 Red Hat Enterprise Linux 存储库的软件包中的应用程序和库，您可以从其它渠道获得单独的debuginfo 和 debugsource 软件包。

需要调试信息来调试代码。对于从软件包安装的代码，GNU Debugger(GDB)自动识别缺少的调试信息，解析软件包名称并提供有关如何获取软件包的具体建议。

您可以通过定位可执行文件，然后查找安装它的软件包来手动确定您需要安装哪些 debuginfo 软件包。

Red Hat Enterprise Linux 包含 GNU 调试器(GDB)，允许您通过命令行用户界面调查程序内部发生了什么情况。

为了检查进程，必须将 GDB 附加到 进程。

$ gdb program

使用程序的文件名或路径替换 program。

设置 GDB 以开始程序的执行。您可以使用 run 命令在开始执行进程前设置断点和 gdb 环境。

(gdb) file path/to/program

GDB 调试器附加到程序后，您可以使用一些命令来控制程序的执行。

显示程序内部变量的值对于了解程序正在做什么非常重要。GDB 提供了多个您可用来检查内部变量的命令。以下是这些命令中最有用的命令：

通常，仅调查代码的一小部分。断点是标记，告知 GDB 在代码的特定位置停止程序的执行。断点通常与源代码行关联。在这种情况下，放置断点需要指定源文件和行号。

在很多情况下，让程序执行直到某些数据改变了或被访问是有好处的。以下示例是最常见的用例。

些程序使用分叉或线程来实现并行代码执行。调试多个同步执行路径需要特殊考虑。

GDB 使用 当前线程 的概念。默认情况下，命令仅应用于当前线程。

红帽企业 Linux 提供用于分析应用程序的交互的多种工具。

The strace 工具启用监控应用执行的系统（内核）调用。

$ strace ... |& tee your_log_file.log

ltrace 工具支持监控应用程序对库中可用功能（共享对象）的调用。

$ ltrace ... |& tee your_log_file.log

SystemTap 工具启用为内核事件注册自定义事件处理程序。与 strace 工具相比，它更难使用，但更有效，并支持更复杂的处理逻辑。SystemTap 脚本名为 trace.stp， 与 SystemTap 一同安装，并且使用 SystemTap 提供对 strace 功能的估测。

GNU Debugger(GDB)可让您在程序执行过程中出现的各种情况下停止执行。要在程序执行系统调用时停止执行，请使用 GDB 捕获点。

GNU Debugger(GDB)可让您在程序执行过程中的不同情况下停止执行。要在程序收到操作系统信号时停止执行,请使用 GDB 捕获点。

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

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

$ ulimit -a

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

systemd 的 coredumpctl 工具可显著简化崩溃机器中使用内核转储的工作。此流程概述了如何捕获未响应进程的内核转储。

内核转储调试的工作流允许分析程序的状态离线。在某些情况下，您可以将此工作流用于仍在运行的程序，例如难以通过 进程访问环境。您可以使用 gcore 命令转储仍在运行的任何进程的内存。

您可以将进程内存标记为不转储。这样可以节省资源并在进程内存包含敏感数据时确保额外的安全性：例如，银行或记帐应用程序或整个虚拟机上。内核内核转储(kdump)和手动内核转储(gcore，GDB)都不会转储以这种方式标记的内存。

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

GCC Toolset 9 提供了以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-9 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-9 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-9 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-9 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

GCC Toolset 10 提供以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-10 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-10 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-10 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-10 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

GCC Toolset 11 提供以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-11 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-11 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-11 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-11 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

GCC Toolset 12 提供以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-12 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-12 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-12 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

在某些情况下，由于 GCC Toolset 12 中的 annobin 和 gcc 之间的同步问题，您的编译可能会失败，并显示类似如下的错误消息：

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

要临时解决这个问题，请从 annobin.so 文件中创建一个符号链接到 gcc-annobin.so 文件中：

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

使用您系统中使用的构架替换 architecture ：

GCC Toolset 13 提供以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-13 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-13 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-13 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

在某些情况下，由于 GCC Toolset 13 中 annobin 和 gcc 之间的同步问题，您的编译可能会失败，并显示类似如下的错误消息：

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

要临时解决这个问题，请从 annobin.so 文件中创建一个符号链接到 gcc-annobin.so 文件中：

# cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin
# ln -s annobin.so gcc-annobin.so

使用您系统中使用的构架替换 architecture ：

GCC Toolset 14 提供以下工具和版本：

GCC Toolset 中的 GCC 编译器可以使用以下 C++ 标准：

所有语言标准均可在符合标准的变体或 GNU 扩展中找到。

将与 GCC Toolset 构建的对象与通过 RHEL 工具链构建的对象（particularly. o 或. a 文件）混合时，应将 GCC Toolset 工具链用于任何链接。这可确保任何仅由 GCC Toolset 提供的更新库功能在链接时得以解决。

$ scl enable gcc-toolset-14 'gcc -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-14 'gcc objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 GCC 版本时，这个建议也适用。

$ scl enable gcc-toolset-14 'ld -lsomelib objfile.o'

以这种方式使用 GCC Toolset 中的库会导致 未定义引用的 符号链接器错误消息。要防止这个问题，请遵循标准链接实践，并在指定对象文件的选项后指定添加库的选项：

$ scl enable gcc-toolset-14 'ld objfile.o -lsomelib'

请注意，在使用基本 Red Hat Enterprise Linux 的 binutils 版本时，这个建议也适用。

在某些情况下，由于 GCC Toolset 14 中的 annobin 和 gcc 之间的同步问题，您的编译可能会失败，并显示类似如下的错误消息：

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

要临时解决这个问题，请从 annobin.so 文件中创建一个符号链接到 gcc-annobin.so 文件中：

# cd /opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin
# ln -s annobin.so gcc-annobin.so

使用您系统中使用的构架替换 architecture ：

GCC Toolset 14 容器镜像中提供的工具版本与 GCC Toolset 14 组件版本 匹配。

下面的部分论述了如何访问并运行 GCC Toolset 容器镜像。

本例演示了如何拉取和开始使用 GCC Toolset 14 Toolchain 容器镜像。

下面的部分描述了如何：

下面的部分论述了如何使用 annocheck 检查：

使用 annobin 会增加二进制文件的大小。要减少使用 an nobin 编译的二进制文件的大小， 您可以删除冗余 annobin 备注。要删除冗余的 annobin 注释，请使用 objcopy 程序，该程序是 binutils 软件包的一部分。

在某些情况下，由于 GCC Toolset 12 中的 annobin 和 gcc 之间的同步问题，您的编译可能会失败，并显示类似如下的错误消息：

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

要临时解决这个问题，请从 annobin.so 文件中创建一个符号链接到 gcc-annobin.so 文件中：

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

使用您系统中使用的构架替换 architecture ：