共享库

原文链接 点击打开链接http://www.ibm.com/developerworks/cn/linux/l-lpic1-102-3/

概述

在本教程中，学习找到并加载 Linux 程序所需的共享库。学习：

• 确定程序需要哪些库
• 了解系统如何查找共享库
• 加载共享库

---

回页首

共享库

在编写程序时，您会依靠其他人已经写好的许多代码来执行例程或特殊功能。 这些代码存储在共享库中。要使用它们，需要将它们与您的代码相链接，无论是在构建程序时还是在运行程序时。

页首

静态和动态链接

Linux 系统有两种类型的可执行程序：

• 静态链接可执行程序：包含它们需要执行的所有库函数；所有库函数都链接到可执行程序中。它们是完整的程序，其运行不依赖于外部库。静态链接程序的一个优势是，它们不需要安装必须具备的软件即可运行。
• 动态链接可执行程序：一些小得多的程序；它们需要来自外部共享库的函数才能运行，因此它们是不完整的。除了更小之外，动态链接还允许程序包指定必须具备的库，而不必将这些库包含在程序包中。通过使用动态链接，许多运行的应用程序可以共享一个库的副本，这样就不会使用相同代码的许多服务来占用内存。出于这些原因，当今大多数程序都采用了动态链接。

在许多 Linux 系统上，有一个有趣的示例，即 ln 命令 (/bin/ln)，它在文件之间创建链接，不论是硬 链接还是软（或者符号）链接。该命令使用了共享库。共享库通常涉及库的通用名称与库的特定级别之间的符号链接，所以如果因为某种原因链接没有出现或已断开，那么ln 命令本身可能无法起作用，并会导致一个循环问题。为了防止出现这种可能性，一些 Linux 系统包含了 ln 程序的静态链接版本作为sln 程序 (/sbin/sln)。清单 1 演示了动态链接 ln 和静态链接 sln 在大小上的巨大差异。该示例来自一个 Fedora 22 64 位系统。

清单 1. sln 和 In 的大小

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ls -l /sbin/sln /bin/ln
-rwxr-xr-x.1 root root  58656 May 14 04:56 /bin/ln
-rwxr-xr-x.1 root root 762872 Feb 23 10:36 /sbin/sln

---

回页首

需要哪些库？

尽管当前的 LPI 考试不要求了解这个主题，但您应该知道，当今许多 Linux 系统都允许在同时支持 32 位和 64 位可执行程序的硬件上运行。因此，许多库被编译为 32 位和 64 位版本。64 位版本通常存储在文件系统的 /lib64 树下，而 32 位版本位于传统的 /lib 树下。在典型的 64 位 Linux 系统上，您可能会同时找到 /lib/libc-2.11.1.so 和 /lib64/libc-2.11.1.so。这两个库允许 32 位和 64 位 C 程序在 64 位 Linux 系统上运行。

ldd 命令

除了知道静态链接程序可能很大之外，您如何确定程序是否为静态链接？如果它是动态链接的，您如何知道它需要哪些库？ldd 命令可以回答这两个问题。如果运行 Debian 或 Ubuntu 等系统，您可能找不到 sln 可执行程序，因此您可能想要检查 /sbin/ldconfig 可执行程序。 清单 2显示了 ln 和 sln 可执行程序以及 ldconfig 可执行程序的ldd 命令的输出。该示例来自一个 Fedora 22 64 位系统 (atticf20)。为了进行比较，我们显示了 Ubuntu 14 32 位系统 (attic-u14) 对于 /bin/ln 的输出。

清单 2. sln 和 In 的 ldd 命令的输出

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ldd /sbin/sln /sbin/ldconfig /bin/ln
/sbin/sln:
	not a dynamic executable
/sbin/ldconfig:
	not a dynamic executable
/bin/ln:
	linux-vdso.so.1 (0x00007ffedd31e000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f2d3bd5d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2d3c11d000)

ian@attic-u14:~/data/lpic-1$ # Ubuntu 14 32-bit
ian@attic-u14:~/data/lpic-1$ ldd /bin/ln
	linux-gate.so.1 =>  (0xb779d000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75d7000)
	/lib/ld-linux.so.2 (0xb77a0000)

因为 ldd 实际上与动态链接有关，这告诉我们 sln 和 ldconfig 都是静态链接的，它们“不是一个动态可执行程序”，同时告诉我们ln 命令所需的三个共享库的名称（linux-vdso.so.1、libc.so.6 和 /lib64/ld-linux-x86-64.so.2）。请注意，.so 表明这些是共享对象 或动态库。此输出还演示了您可能想了解的三种不同类型的信息。

linux-vdso.so.1

是 Linux 虚拟动态共享对象，我们稍后将讨论它。您还可以像在 Ubuntu 14 示例中一样看到 linux-gate.so.1。

libc.so.6

有一个指向 /lib64/libc.so.6 或 /lib/i386-linux-gnu/libc.so.6 的指针。 您还可以看到，该指针指向旧版 32 位系统上的 /lib/libc.so.6。

/lib64/ld-linux-x86-64.so.2

是另一个库的绝对路径。

在 清单 3 中，我使用了 ls -l 命令来依次显示最后两个库，它们是这些库的特定版本的动态链接。该示例来自一个 Fedora 22 64 位系统。 这使得在安装库更新时，无需重新链接使用该库的可执行程序。

清单 3. 库符号链接

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ls -l /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx.1 root root 10 Feb 23 10:33 /lib64/ld-linux-x86-64.so.2 -> ld-2.21.so
lrwxrwxrwx.1 root root 12 Feb 23 10:33 /lib64/libc.so.6 -> libc-2.21.so

Linux 虚拟动态共享对象

在 x86 处理器发展的早期，用户程序与管理服务之间的通信是通过软件中断来实现的。随着处理器速度的提高，这已成为一个严重的瓶颈。自 Pentium® II 处理器开始，Intel ®引入了一个Fast System Call 装置来提高系统调用速度，使用 SYSENTER 和 SYSEXIT 指令而不是中断来提高速度。

您看到的库 linux-vdso.so.1 是一个虚拟库，或者说是虚拟动态共享对象，它只位于每个程序的地址空间中。一些系统将它称为 linux-gate.so.1。这个虚拟库提供了必要的逻辑，允许用户程序通过特殊处理器上可用的更快方法来访问系统函数，无论该方法是中断还是大多数较新的处理器中采用的快速系统调用。

---

回页首

动态加载

通过前面的内容，您可能会惊奇地发现 /lib/ld-linux.so.2 和它的 64 位版本 /lib64/ld-linux-x86-64.so.2（看上去都像是共享库）实际上是都是独立的可执行程序。它们是负责动态加载的代码。它们读取可执行程序的标头信息，该信息为 Executable and Linking Format (ELF) 格式。它们根据此信息确定需要哪些库，以及需要加载哪些库。然后执行动态链接来安排好可执行程序和已加载的库中的所有地址指针，让程序能够运行。

ld-linux.so 的手册页也描述了 ld.so，后者为早期的 a.out 二进制格式执行了类似的功能。清单 4演示了使用 ld-linux.so 的--list 选项来显示与 清单 2ldd 命令中显示的信息相同的 ln 命令的信息。

清单 4. 使用 ld-linux.so 显示库需求

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ /lib64/ld-linux-x86-64.so.2 --list /bin/ln
	linux-vdso.so.1 (0x00007ffe725f6000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f2179b5d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2179f1d000)

ian@attic-u14:~$ # Ubuntu 14 32-bit
ian@attic-u14:~$ /lib/ld-linux.so.2 --list /bin/ln
	linux-gate.so.1 =>  (0xb77bc000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75f6000)
	/lib/ld-linux.so.2 (0xb77bf000)

请注意，两个清单中的十六进制地址可能有所不同。如果运行 ldd 两次，它们可能也是不同的。

---

回页首

动态库配置

那么动态加载程序如何知道从何处查找可执行程序？对于 Linux 上的许多问题，/etc 中都有一个配置文件。事实上，有两个配置文件：/etc/ld.so.conf 和 /etc/ld.so.cache。 清单 5显示了 64 位 Fedora 22 系统上的 /etc/ld.so.conf 的内容。请注意，/etc/ld.so.conf 指定所有来自子目录 ld.so.conf.d 的 .conf 文件都应被包含。旧版系统可能拥有 /etc/ld.so.conf 中的所有条目，而不包含来自 /etc/ld.so.conf.d 目录的条目。在您的系统上，/etc/ld.so.conf 或 /etc/ld.so.conf.d 目录的实际内容可能有所不同。

清单 5. /etc/ld.so.conf 的内容

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
[ian@atticf20 ~]$ ls /etc/ld.so.conf.d/*.conf
/etc/ld.so.conf.d/atlas-x86_64.conf
/etc/ld.so.conf.d/bind99-x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.4-301.fc22.x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.4-303.fc22.x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.6-300.fc22.x86_64.conf
/etc/ld.so.conf.d/libiscsi-x86_64.conf
/etc/ld.so.conf.d/llvm-x86_64.conf
/etc/ld.so.conf.d/mariadb-x86_64.conf

程序加载必须很快，因此可以使用 ldconfig 命令来处理 ld.so.conf 文件、ld.so.conf.d 中包含的所有文件、受信任的目录中的库、/lib 和 /usr/lib，以及命令行上受支持的其他所有内容。ldconfig 命令在 /etc/ld.so.cache 中为最近使用的共享库创建了必要的链接和缓存。动态加载程序使用来自 ld.so.cache 的缓存信息来加载要动态加载和链接的文件。如果更改 ld.so.conf（或将新包含的文件添加到 ld.so.conf.d 中），则必须（以根用户身份）运行 ldconfig 命令来重新构建 ld.so.cache 文件。

通常，在不用参数的情况下使用 ldconfig 命令来重新构建 ld.so.cache。还可以指定其他一些参数来覆盖这种默认行为。一般情况下，可以尝试使用 man ldconfig 获取更多的信息。清单 6 演示了使用 -p 参数来显示 ld.so.cache 的内容。

清单 6. 使用 ldconfig 显示 ld.so.cache

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ /sbin/ldconfig -p | less
1361 libs found in cache `/etc/ld.so.cache'
        p11-kit-trust.so (libc6,x86-64) => /lib64/p11-kit-trust.so
        libzeitgeist-2.0.so.0 (libc6,x86-64) => /lib64/libzeitgeist-2.0.so.0
        libzapojit-0.0.so.0 (libc6,x86-64) => /lib64/libzapojit-0.0.so.0
        libz.so.1 (libc6,x86-64) => /lib64/libz.so.1
        libyelp.so.0 (libc6,x86-64) => /lib64/libyelp.so.0
        libyaml-0.so.2 (libc6,x86-64) => /lib64/libyaml-0.so.2
        libyajl.so.2 (libc6,x86-64) => /lib64/libyajl.so.2
        libxtables.so.10 (libc6,x86-64) => /lib64/libxtables.so.10
        libxslt.so.1 (libc6,x86-64) => /lib64/libxslt.so.1
        libxshmfence.so.1 (libc6,x86-64) => /lib64/libxshmfence.so.1
        libxml2.so.2 (libc6,x86-64) => /lib64/libxml2.so.2
        libxmlrpc_util.so.3 (libc6,x86-64) => /lib64/libxmlrpc_util.so.3
        libxmlrpc_server_cgi.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_cgi.so.3
        libxmlrpc_server_abyss.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_abyss.so.3
        libxmlrpc_server.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server.so.3
        libxmlrpc_client.so.3 (libc6,x86-64) => /lib64/libxmlrpc_client.so.3
        libxmlrpc_abyss.so.3 (libc6,x86-64) => /lib64/libxmlrpc_abyss.so.3
        libxmlrpc.so.3 (libc6,x86-64) => /lib64/libxmlrpc.so.3
        libxml-security-c.so.16 (libc6,x86-64) => /lib64/libxml-security-c.so.16
        libxlutil.so.4.3 (libc6,x86-64) => /lib64/libxlutil.so.4.3
        libxklavier.so.16 (libc6,x86-64) => /lib64/libxklavier.so.16
        libxkbfile.so.1 (libc6,x86-64) => /lib64/libxkbfile.so.1
:

---

回页首

加载特定的库

如果正在运行需要一个特定旧版共享库的旧版应用程序，或者正在开发新的共享库或一个共享库的新版本，您可能希望覆盖加载程序使用的默认搜索路径。使用可能安装在 /opt 树中的特定于产品的共享库的脚本可能也需要这一功能。

就像可以设置 PATH 变量来为可执行程序指定搜索路径一样，可以将 LD_LIBRARY_PATH 变量设置为一个以冒号分隔的目录列表，应该首先在这个列表中搜索共享库，然后再在 ld.so.cache 中指定的系统目录中进行搜索。例如，您可以使用一个类似下面命令的命令：

export LD_LIBRARY_PATH=/usr/lib/oldstuff:/opt/IBM/AgentController/lib

请参见参考资料，获取更多细节和本系列中其他教程的链接。

我们对在 Linux 上管理共享库的简单介绍到此就结束了。