实例先行，

1，情景

三互相依赖的小项目：

（1）libbottom.so，无特别依赖，除系统文件

（2）libtop.so，依赖libbottom.so

（3）app 可执行程序，依赖libtop.so

2，具体实现及问题

2.1 bottom

bottom.cpp

//bottom.cpp
#include "bottom.h"
#include <stdio.h>int bottom(int a, int b)
{//printf("bottom() running\n");return a+b;}

bottom.h

//bottom.h
#pragma once
#ifdef __cplusplus
extern "C" {
#endifint bottom(int a, int b);#ifdef __cplusplus
}
#endif

Makefile

LIB := libbottom.so%.o: %.cppg++ -fPIC $< -c -o $@$(LIB): bottom.og++ -shared $< -o $@.PHONY: clean
clean:-rm -rf $(LIB) *.o

需要留意 tab健

编译：

2.2 top

top.cpp

//top.cpp
#include "top.h"
#include <stdio.h>int top(int a, int b, int c)
{printf("top() running\n");return bottom(a, b) + c;}

top.h

//top.h
#pragma once#include "bottom.h"#ifdef __cplusplus
extern "C" {
#endifint top(int a, int b, int c);#ifdef __cplusplus
}
#endif

Makefile

LIB := libtop.soINC := -I ${'pwd'}../bottom/
LD_FLAGS := -L ${'pwd'}../bottom/ -lbottom
%.o: %.cppg++ -fPIC $< -c -o $@ $(INC) $(LD_FLAGS)$(LIB): top.og++ -shared $< -o $@.PHONY: clean
clean:-rm -rf $(LIB) *.o

编译：

2.3 app

hello_top_bottom.cpp

//hello_top_bottom.cpp
#include "top.h"
#include <stdio.h>
int main()
{int x = 3, y = 4, z = 5;int sum = 0;sum = top(x, y, z);printf("sum = %d\n", sum);return 0;
}

Makefile
 

EXE := hello_top_bottomall: $(EXE)INC := -I ${PWD}/../top/ -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../top/ -ltop -L ${PWD}/../bottom/ -lbottom%: %.cppg++ $< -o $@ $(INC) $(LD_FLAGS).PHONY: clean
clean:-rm -rf $(EXE)

编译运行：

这种情况下，如何运行起来呢？

使用LD_LIBRARY_PATH 环境变量：

export LD_LIBRARY_PATH=../top/

此时能够找到 libtop.so,但是找不到 libbottom.so

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../bottom/

这时候可以找到 libbottom.so

 以上为常用方法。

3，回退问题

3.1 取消 LD_LIBRARY_PATH的赋值

export LD_LIBRARY_PATH=

这样，即使编译通过，又回到了找不到 libtop.so的状态：

3.2 构建 app时不链接 bottom 库

将 app/Makefile 修改为不链接 libbottom.so   ：

EXE := hello_top_bottomall: $(EXE)INC := -I ${PWD}/../top/ -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../top/ -ltop
#-L ${PWD}/../bottom/ -lbottom%: %.cppg++ $< -o $@ $(INC) $(LD_FLAGS).PHONY: clean
clean:-rm -rf $(EXE)

此时又回到了无法编译的状态：

提示 rpath，我们来试一下

3.3 对 top 使用 rpath

只修改 top/Makefile 为：

LIB := libtop.soINC := -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../bottom/ -lbottom -Wl,-rpath=../bottom/%.o: %.cppg++ -fPIC $< -c -o $@ $(INC)#       $(LD_FLAGS)$(LIB): top.og++ -shared $< -o $@ $(LD_FLAGS).PHONY: clean
clean:-rm -rf $(LIB) *.o

然后再编译app，此时可以编译通过，但是依然不能运行：

此时配置 LD_LIBRARY_PATH，只需要配置 top 的路径，即可运行，不需要配置bottom的路径：

export LD_LIBRARY_PATH=../top/

 

其中，libtop.so 是靠 LD_LIBRARY_PATH 提供的线索找到的

而 libbottom.so 是靠 链接生成 libtop.so 时 指定的 -rpath 找到的。

4.0 如果指定rpath 的路径与 LD_LIBRARY_PATH 指向的路径不同

这个实验我们通过 top 依赖的 bottom 来进行，

准备另一份 libbottom.so:

当通过指定新的环境变量后

export LD_LIBRARY_PATH=/home/archer/ex_rpath/local:$LD_LIBRARY_PATH

发现top通过rpath指向的libbottom.so 被 LD_LIBRARAY_PATH        取代。

5.  通过分析 readelf -d libtop.so

在gcc 11 中，只有RUNPATH，

原因：

在一些情况下，特别是在较新版本的 GCC 中（如 GCC 11），生成的 ELF 文件可能会只包含 RUNPATH 而不包含 RPATH。这是因为 RUNPATH 是一种更加灵活和推荐的方式来指定运行时库的搜索路径，相比之下，RPATH 的使用可能存在一些安全和可维护性上的问题。

主要区别在于：

• RPATH 是在链接时硬编码到 ELF 文件中的搜索路径，优先级低于系统默认路径和 LD_LIBRARY_PATH 环境变量。

• RUNPATH 也是指定运行时库的搜索路径，但优先级高于系统默认路径和 LD_LIBRARY_PATH 环境变量，且可以被覆盖。

因此，如果你在使用 GCC 11 生成的 ELF 文件中只看到 RUNPATH 而没有 RPATH，这是符合最新标准和最佳实践的做法。RUNPATH 提供了更灵活和可控的方式来管理共享库的搜索路径，有助于提高系统的安全性和可维护性。

6，运行时搜索 libxx.so 的优先级

搜索.so的优先级顺序

1.    RPATH： 本信息由 elf 文件提供
2.   LD_LIBRARY_PATH： 这是环境变量
3.   RUNPATH：本信息也由 elf 文件提供
4.    ldconfig的缓存： 通过配置/etc/ld.conf*来修改
5.    默认的系统路径：/lib, /usr/lib

故，通过LD_LIBRARY_PATH 提供的路径中的 libbottom.so 会优先被搜索到。

7，-Wl,rpath-link

-Wl,rpath-link 是设置编译链接时候的搜索顺序，格式跟rpath 的设置一样，而rpath 是设置运行时的搜索顺序；