实例先行，
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
}
#endifMakefile
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 是设置运行时的搜索顺序；
