深入探索Linux中的ldd机制 (linux ldd)

在linux系统中，ldd是一个非常实用的命令，它可以用来查看一个可执行程序或动态链接库所需要的依赖项。通过使用ldd命令，我们可以，了解它是如何工作的，以及在实际的开发中如何使用它。

一、ldd的基本用法

ldd命令的基本用法非常简单，只需要在终端输入ldd加上对应的可执行程序或动态链接库文件路径即可查看依赖项。例如，我们可以使用以下命令查看一个测试程序hello的依赖关系：

“`

ldd ./hello

“`

执行结果会输出hello程序所依赖的动态链接库，例如：

“`

linux-vdso.so.1 => (0x00007fff541b7000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f21c45f1000)

/lib64/ld-linux-x86-64.so.2 (0x00007f21c49d2023)

“`

其中，linux-vdso.so.1是一个虚拟的共享库，不会存在真正的文件中，而是在内核中实现的。libc.so.6是C标准库的动态链接库，是任何Linux程序的基础依赖项。/lib64/ld-linux-x86-64.so.2是默认的动态链接器，也是一个必需的依赖项，它负责在进程启动时将程序的依赖项加载到内存中。

二、ldd的工作原理

在Linux中，程序和库通常是以ELF格式存储的，其中包含了程序的代码、数据、符号和其他相关信息。而ldd命令则是通过解析这些ELF文件来查找依赖关系的。

在执行ldd命令后，它首先会读取程序的ELF头部信息，然后查找它所依赖的动态链接库列表。每个动态链接库都有一个DT_NEEDED结构，它包含了依赖库的名字和路径。ldd命令会根据这些信息来查找动态链接库，并输出到终端中。

除了查找动态链接库，ldd命令还可以检查可执行文件中的符号表，以验证它们是否已正确地解析。如果符号表中存在未解析的符号，说明程序无法正常运行，需要先解决这些依赖问题。

三、ldd在实际开发中的应用

在实际开发中，ldd命令是一个非常有用的工具，可以帮助我们快速定位和解决依赖问题。以下是一些常见的用法：

1. 查找缺失的动态链接库

如果程序无法正常运行，或者在执行时提示缺失某些库文件，我们可以通过ldd命令来查找缺失的动态链接库。例如：

“`

$ ldd ./hello

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f21c45f1000)

libm.so.6 => not found

libgcc_s.so.1 => not found

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f21c43d4000)

/lib64/ld-linux-x86-64.so.2 (0x00007f21c49d2023)

“`

可以看到，上面的输出结果中，程序缺失了libm.so.6和libgcc_s.so.1两个库文件。我们需要先安装这些库文件，才能正常运行程序。

2. 检查动态链接库版本号

有时候，程序需要依赖的库文件可能与当前系统安装的版本不匹配，这可能导致一些意想不到的问题。通过ldd命令，我们可以检查动态链接库的版本号，以确保它们与程序的要求相符。例如：

“`

$ ldd -v ./hello | grep libc.so.6

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f21c45f1000)

ld-linux-x86-64.so.2 (0xdeadbeef)

“`

通过这个命令，我们可以看到，程序要求的libc.so.6的版本号与当前系统中安装的版本完全一致，因此不会出现版本不匹配的问题。

3. 检查符号表解析

当程序中存在未解析的符号时，会导致程序无法正常运行。通过ldd命令，我们可以检查程序的符号表，以验证它们是否已正确地解析。例如：

“`

$ ldd -r ./hello

linux-vdso.so.1 => (0x00007ffd3595e000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5cd5b46000)

/lib64/ld-linux-x86-64.so.2 (0x00007f5cd5ee7000)

“`

在这个例子中，我们使用了ldd的-r选项来检查hello程序的符号表，如果符号表中存在 unresolved symbols，则会输出对应的错误信息。

综上所述，ldd命令在Linux系统中是一个非常重要的工具，可以帮助我们快速定位和解决依赖问题，确保程序能够正常运行。通过，我们可以更好地理解它的工作原理，并在实际的开发中更好地运用它。

相关问题拓展阅读：

• Linux和FreeBSD在使用非系统自带的gcc时的区别

Linux和FreeBSD在使用非系统自带的gcc时的区别

下面拿CentOS 5和FreeBSD 9.0做下比较：

CentOS 5 自带的gcc是gcc (GCC) 4.1.2，通过yum可以安装gcc44 (GCC) 4.4.4

FreeBSD 9.0 自带的gcc是gcc (GCC) 4.2.1，通过ports可以安装gcc 4.6 (目前是4.6.2）

用C++写一个非常简单的C++程序：

int main(){

return 0;

}

然后用g++编译:

# g++44 main.cpp -o main

然后用ldd查看，Linux下的输出结果为：

libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0xf000000)

libm.so.6 => /lib64/libm.so.6 (0xcc00000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0xe400000)

libc.so.6 => /lib64/libc.so.6 (0xc400000)

/lib64/ld-linux-x86-64.so.2 (0xc000000)

FreeBSD下的输出结果为：

libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0×)

libm.so.5 => /lib/libm.so.5 (0x800b59000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d7a000)

libc.so.7 => /lib/libc.so.7 (0x800f87000)

其中有两行故意标红了。因为他们是来自于gcc。那么就有这么一个问题：不同版本的gcc，这两个库，一样吗？或者我这么问，gcc 4.4、gcc 4.6、gcc 4.2、gcc 4.1相比，他们的C++标准库(libstdc++.so)的接口一样吗？ 实现一样吗？（此处指需要被编译的那部分，如非模板类）

来看看CentOS怎么做的：

CentOS 5的gcc44-c++这个包，只带了两个so。/usr/lib/gcc/x86_64-redhat-linux6E/4.4.4/32/libstdc++.so和/usr/lib/gcc/x86_64-redhat-linux6E/4.4.4/libstdc++.so。而这两个so竟然只是文本文件，内容大概是这样：

INPUT ( -lstdc++_nonshared /usr/lib64/libstdc++.so.6 )

也就是说，它会静态链接到/usr/lib/gcc/x86_64-redhat-linux6E/4.4.4/libstdc++_nonshared.a这个文件，并动态链接到/usr/lib64/libstdc++.so.6（这个文件由gcc 4.1提供）

所以，在CentOS 5中，用gcc 4.4编译出来的东西，运行环境不需要安装gcc 4.4 !

然后看FreeBSD怎么做的：

gcc 4.6的so，安装在/usr/local/lib/gcc46/目录下。如果是在64位环境下安装的，那么只有64位版本的，没有32位版本的。最关键的是，它确实是一个elf格式的so，而不是文本文件、软链接什么的。

如果在FreeBSD下这么编译一个文件：

# g++46 -o t test.cpp

那么它会错误的链接到4.2的so上

libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0×)

libm.so.5 => /lib/libm.so.5 (0x800b59000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d7a000)

libc.so.7 => /lib/libc.so.7 (0x800f87000)

程序还能不能正常工作，那就看天命了。正确的做法是，在链接的时候加上-Wl,-rpath=/usr/local/lib/gcc46 。

现在如果只是为了让ports用gcc 4.6，那么直接在/etc/make.conf中加入“USE_GCC=4.6”即可.

关于linux ldd的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。