2.3. 将库与 GCC 搭配使用

用于库的一个特殊文件名称规则：例如称为 foo 的库一般会有文件 libfoo.so 或 libfoo.a。通过 GCC 的链接输入选项（而非输出选项）自动理解此约定：

开发人员可以选择使用完整编译语言构建应用时使用静态或动态链接。了解静态和动态链接之间的区别很重要，特别是在 Red Hat Enterprise Linux 上使用 C 和 C++ 语言的上下文中。总之，红帽不建议在 Red Hat Enterprise Linux 的应用程序中使用静态链接。

可使用多种方式比较动态和静态链接：

因为存在这里列出的缺陷，应尽可能避免使用静态链接，特别是整个应用程序以及 glibc 和 libstdc++ 库。

链接时间优化(LTO)可让编译器通过在链接时使用其中间表示，在程序的所有转换单元中执行各种优化。因此，您的可执行文件和库会较小并更快地运行。另外，您可以使用 LTO 在编译时分析软件包源代码，从而改进了潜在的编码错误的各种 GCC 诊断。

库是可以在您的程序中重复使用的代码软件包。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 linker 提供了选项 -Bstatic 和 -Bdynamic 以指定此选项后的库是否应静态链接或动态链接。将 -Bstatic 和库传递给 linker 后，必须手动恢复默认的动态链接行为，才能将以下库与 -Bdynamic 选项动态链接。

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

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