-Wl,-rpath= 编译器链接器指定动态库路径 与 LD_LIBRARY_PATH

实例先行，

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" {
#endif

int bottom(int a, int b);

#ifdef __cplusplus
}
#endif

 

Makefile

LIB := libbottom.so

%.o: %.cpp
    g++ -fPIC $< -c -o $@

$(LIB): bottom.o
    g++ -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" {
#endif

int top(int a, int b, int c);

#ifdef __cplusplus
}
#endif

Makefile

LIB := libtop.so

INC := -I ${'pwd'}../bottom/
LD_FLAGS := -L ${'pwd'}../bottom/ -lbottom
%.o: %.cpp
    g++ -fPIC $< -c -o $@ $(INC) $(LD_FLAGS)

$(LIB): top.o
    g++ -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_bottom

all: $(EXE)

INC := -I ${PWD}/../top/ -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../top/ -ltop -L ${PWD}/../bottom/ -lbottom


%: %.cpp
    g++ $< -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_bottom

all: $(EXE)

INC := -I ${PWD}/../top/ -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../top/ -ltop
#-L ${PWD}/../bottom/ -lbottom


%: %.cpp
        g++ $< -o $@ $(INC) $(LD_FLAGS)

.PHONY: clean
clean:
        -rm -rf $(EXE)

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

提示 rpath，我们来试一下

3.3 对 top 使用 rpath

只修改 top/Makefile 为：

LIB := libtop.so

INC := -I ${PWD}/../bottom/
LD_FLAGS := -L ${PWD}/../bottom/ -lbottom -Wl,-rpath=../bottom/

%.o: %.cpp
        g++ -fPIC $< -c -o $@ $(INC)

#       $(LD_FLAGS)

$(LIB): top.o
        g++ -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 是设置运行时的搜索顺序；