rpath和runpath的区别

考虑翻译Qt官方blog中的RPATH and RUNPATH这篇文章，在继续之前，我需要先验证自己的理解是正确的，至少能自圆其说，能说服自己。

用例子说话

	二进制	对应源码
有一个程序	a.out	main.c
需要加载插件A	libA.so	liba.c
A需要另一个动态库	libB.so	libB1.c 或 libB2.c

本文的关注点就是：到底是哪一个libB.so被加载

目录结构：

/home/debao/ttt/a.out
/home/debao/ttt/libA.so
/home/debao/ttt/libB.so
/usr/lib/libB.so

具体源码

main.c ==> ./a.out

#include <stdio.h>
#include <dlfcn.h>
typedef int (*funcA)(int, int);
int main()
{
    void * plugin = dlopen("./libA.so", RTLD_LAZY);
    funcA f = (funcA)dlsym(plugin, "funcA");
    printf("main: %d\n", f(3,4));
    return 0;
}

liba.c ==> ./libA.so

#include <stdio.h>
int funcB(int, int);
int funcA(int a, int b)
{
    printf("hello from funcA\n");
    return funcB(a, b);
}

libb1.c ==> ./libB.so

#include <stdio.h>
int funcB(int a, int b)
{
    printf("Hello from funcB 1\n");
    return a*b;
}

libb2.c ==> /usr/lib/libB.so

#include <stdio.h>
int funcB(int a, int b)
{
    printf("Hello from funcB 2\n");
    return a*b;
}

编译库文件

编译动态库libB.so

$ gcc -shared -fPIC libb2.c -o libB2.so
$ sudo mv libB2.so /usr/lib/libB.so
$ gcc -shared -fPIC libb.c -o libB.so

编译动态库libA.so

$ gcc -shared -fPIC liba.c -o libA.so -L. -lB

顺便看看该elf文件的头部信息：

$ readelf libA.so -d

Dynamic section at offset 0xf20 contains 21 entries:
  Tag        Type      Name/Value
 0x00000001 (NEEDED)   Shared library: [libB.so]
 0x00000001 (NEEDED)   Shared library: [libc.so.6]
...

恩，只有库的文件名信息，而没有路径信息。

编译程序

第一次编译运行（什么路径都不加）

$ gcc main.c -ldl
$ ./a.out
hello from funcA
Hello from funcB 2
main: 12

程序：dlopen从当前目录找到libA.so，然后却在/usr/lib/中找到libB.so（没有使用当前目录的libB.so，这是我们需要的么？）

第二次编译运行（使用DT_RPATH）

$ gcc main.c -ldl  -Wl,--rpath=.
$ ./a.out
hello from funcA
Hello from funcB 1
main: 12

恩，使用当前目录的libB.so，很理想的东西

可是，由于DT_RPATH无法被环境变量LD_LIBRARY_PATH覆盖，不是不建议被使用，而是建议使用DT_RUNPATH么？
第三次编译运行（使用DT_RUNPATH）

$ gcc main.c -ldl -Wl,--rpath=.,--enable-new-dtags
$ ./a.out
hello from funcA
Hello from funcB 2
main: 12

问题重新出现，使用的系统路径中的libB.so 而不是当前目录下的。

程序头部信息

通过下列命令可以查看：

$ readelf -d a.out

为了完整起见，列出前面3次编译的程序的信息：

没有rpath和runpath

Dynamic section at offset 0xf20 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8048360
...

包含rpath

Dynamic section at offset 0xf18 contains 22 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [.]
 0x0000000c (INIT)                       0x8048360
....

包含rpath和runpath

Dynamic section at offset 0xf10 contains 23 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [.]
 0x0000001d (RUNPATH)                    Library runpath: [.]

原因

RPATH and RUNPATH给出这个问题的答案：

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

用它解释第一个程序：

libA.so 没有RUNPATH，故而
- 使用其RPATH (没有)
- 递归查找其loader直到链条的顶端（可执行程序或被dlopen打开的对象）的RPATH或者遇RUNPATH退出（没有命中）
- 可执行程序没有RUNPATH，故而
  - 使用其RPATH (没有)
环境变量LD_LIBRARY_PATH，（没有）
libA.so 的RUNPATH (没有)
ld.so.cache (没有命中)
默认路径/usr/lib （命中）

用它解释第二个程序：

libA.so 没有RUNPATH，故而
- 使用其RPATH (没有)
- 递归查找其loader直到链条的顶端（可执行程序或被dlopen打开的对象）的RPATH或者遇RUNPATH退出（没有命中）
- 可执行程序没有RUNPATH，故而
  - 使用其RPATH (命中)

用它解释第三个程序：

libA.so 没有RUNPATH，故而
- 使用其RPATH (没有)
- 递归查找其loader直到链条的顶端（可执行程序或被dlopen打开的对象）的RPATH或者遇RUNPATH退出（没有命中）
- 可执行程序有RUNPATH，(继续前行)
环境变量LD_LIBRARY_PATH，（没有）
libA.so 的RUNPATH (没有)
ld.so.cache (没有命中)
默认路径/usr/lib （命中）

有意思的就是这个程序了，可执行程序的RUNPATH是一个重要的判断条件，却并不被做为这儿搜索路径！！

结束

本文是在kubuntu 11.10下编写测试的。为了尽可能简单，例子也都是认为制造的。而且我们看到，在使用RPATH的时候是正常的，RUNPATH一般来说，被推荐使用，但这儿它却不能正常工作。

所以，当使用RUNPATH时，我们需要明白：某些情况下可能需要设置环境变量 LD_LIBRARY_PATH

rpath和runpath的区别相关推荐

linux动态库加载RPATH,RUNPATH
引用自:http://gotowqj.iteye.com/blog/1926771 链接动态库如何程序在连接时使用了共享库,就必须在运行的时候能够找到共享库的位置.linux的可执行程序在执行的时候 ...
cmake详细教程（经验版）
一.参考资料 CMake DSL语言 CMake 快速入门 cmake使用教程 CMake简明教程 CMake 入门实战 | HaHack Cmake入门和MindsporeLite Cmake文件分 ...
Linux下动态链接库的查找问题
Linux下动态链接库的查找问题上一篇文章我们从 Linux C 编程的角度分析了一下 Linux 中的静态链接库和动态链接库的区别,这篇文章着重从 Linux 编译和运行的角度分析一下 Linux ...
【linux】程序找不到动态库.so的解决办法|查看.so动态库信息|.so动态库加载顺序
目录找不到.so解决方法方法一:添加环境变量方法二:复制so文件到lib路径方法三:(推荐)添加ldconfig寻找路径方法四:在编译目标代码时指定该程序的动态库搜索路径让程序在本目录找到 ...
glibc 知：ld.so
文章目录 1. 名称 2. 概要 3. 描述 3.1. 动态字符串标记 4. 选项 5. 环境 5.1. 安全执行模式 5.2. 环境变量 5.2.1. LD_ASSUME_KERNEL(自 glib ...
bazel 链接第三方动态库_C/C++编程知识：Linux 动态库相关知识整理
动态库和静态库在C/C++开发中很常见,相比静态库直接被编译到可执行程序,动态库运行时加载使得可执行程序的体积更小,更新动态库可以不用重新编译可执行程序等诸多好处.作者是一个Linux后台开发,这些知 ...
Linux系统和程序中的DEP和ASLR保护机制
2014年,OpenSSL加密库中的一个缓冲区溢出漏洞被公开.该缺陷被称为"心脏出血".它使受欢迎的在线服务和软件平台的数亿用户暴露于易受攻击的OpenSSL软件版本中.于是操作系 ...
Lib库使用学习笔记
Lib库使用学习笔记转自:http://blog.csdn.net/macky0668/article/details/6044867 技术前沿 2008-03-31 14:21:10 阅读177 ...
Linux编译之(1)C语言基础
Linux编译之C语言基础 Author:Once Day Date:2023年3月11日漫漫长路,才刚刚开始- 1.概述在Linux下开发多源文件的C代码文件,是一定要了解Makefile的,虽 ...