ld无法找到项目符号链接失败_链接选项rpath的原理和应用

女主宣言

在测试和部署 C&＃43;&＃43; 动态库时&＃xff0c;经常遇到的问题就是程序链接到了系统路径下的动态库&＃xff0c;有时候 make 编译时链接到本地路径的动态库&＃xff0c;但实际 make install 时则会丢失这个依赖。本文将要介绍的就是一种通用解决方法&＃xff0c;使用 RPATH 来绑定链接路径。

PS&＃xff1a;丰富的一线技术、多元化的表现形式&＃xff0c;尽在“360云计算”&＃xff0c;点关注哦&＃xff01;

1

动态库编译和使用简单示例

给出以下示例库&＃xff1a;

// foo.h#pragma once#ifdef __cplusplusextern "C" {#endifvoid foo();#ifdef __cplusplus}#endif

// foo.cc#include "foo.h"#include void foo() { printf("foo\n"); }

生成动态库 libfoo.so&＃xff1a;

g&＃43;&＃43; -o libfoo.so -fPIC -shared foo.cc

然后给出调用代码&＃xff1a;

// main.cc#include "foo.h"int main(int argc, char* argv[]) { foo(); return 0;}

编译时链接到当前目录&＃xff1a;

$ gcc main.c -L . -lfoo$ ./a.out foo$ ldd a.out | grep libfoo libfoo.so (0x00007fc2010f7000)

至此&＃xff0c;一切正常。

2

依赖动态库的动态库

实际编写程序时&＃xff0c;往往会依赖一些第三方库来避免重复造轮子。比如&＃xff0c;这里我们要写一个库依赖于 libfoo.so。

目录层次&＃xff1a;

.├── include│ └── bar.h├── src│ └── bar.cc└── thirdparty ├── include │ └── foo.h └── lib └── libfoo.so

然后编译生成 libbar.so&＃xff1a;

g&＃43;&＃43; -o libbar.so -fPIC -shared src/bar.cc \  -I include/ -I thirdparty/include/ \  -L thirdparty/lib/ -lfoo

问题来了&＃xff0c;编译出的 libbar.so 找不到 libfoo.so 的依赖&＃xff1a;

$ ldd libbar.so | grep foo libfoo.so &＃61;> not found

当然&＃xff0c;这样的话&＃xff0c;你编译依赖 libbar.so 的程序时会直接失败&＃xff0c;从而提醒你去寻找依赖的 libfoo.so&＃xff1a;

/usr/bin/ld: warning: libfoo.so, needed by ./libbar.so, not found (try using -rpath or -rpath-link) ./libbar.so: undefined reference to &＃96;foo&＃39;

注意这里我们第一次见到 rpath 这个概念。

但是问题更大的是&＃xff0c;假如 libfoo.so 是一个旧版的库&＃xff0c;而开发机上有个其他用户完全无视影响&＃xff0c;直接将 libfoo.so 安装到了系统目录&＃xff0c;比如 /usr/lib64 下面。这样&＃xff0c;你的程序依赖的 libbar.so 将会找到系统目录下旧的 libfoo.so&＃xff0c;而不是你自己维护的新版。如果新版 libfoo.so 的 ABI 发生了改变而 API 不变&＃xff1a;

// foo.h#pragma oncevoid foo(int i &＃61; 0);

// foo.cc#include "foo.h"#include void foo(int i) { printf("foo: %d\n", i); }

API 兼容指的是&＃xff0c;调用 foo() 仍然合法&＃xff0c;但是由于 C&＃43;&＃43; 的 name mangling&＃xff0c;带有默认参数的 foo 对应的符号发生了变化&＃xff0c;因此 foo 可能还会出现这样的错误(main.cc 仅仅是调用 bar() 函数&＃xff0c;这里就不贴代码了)&＃xff1a;

$ g&＃43;&＃43; main.cc -L . -lbar./libbar.so: undefined reference to &＃96;foo(int)&＃39;collect2: error: ld returned 1 exit status

查看 libbar.so 的依赖就什么都明白了&＃xff1a;

$ ldd libbar.so | grep libfoo libfoo.so &＃61;> /usr/lib64/libfoo.so (0x00007efd6daf1000)

原因是 foo 的函数签名变成了 void foo(int)&＃xff0c;而链接到的动态库却是全局的 libfoo.so。简单的解决方式是&＃xff0c;将本地库的路径加入 LD_LIBRARY_PATH 中&＃xff1a;

$ export LD_LIBRARY_PATH&＃61;$PWD/thirdparty/lib:$LD_LIBRARY_PATH$ g&＃43;&＃43; main.cc -L . -lbar$ ./a.out barfoo: 0

用 ldd 也能查看 libbar.so 依赖的 libfoo.so 不再是全局的&＃xff0c;而是本地的。但问题是&＃xff0c;如果发布单独的 libbar.so 给用户&＃xff0c;而用户又因为某些原因无法升级全局的 libfoo.so&＃xff0c;那么每次用户都要手动设置 LD_LIBRARY_PATH。

此时&＃xff0c;另一种解决方法刚好能避免这个问题&＃xff0c;也就是使用 rpath。

3

rpath 的使用

rpath 即 runtime path&＃xff0c;运行时路径。既可以指定相对路径也可以指定绝对路径。

编译方式&＃xff1a;

$ g&＃43;&＃43; -o libbar.so -fPIC -shared src/bar.cc \ -I include/ -I thirdparty/include/ \ -L thirdparty/lib/ -lfoo -Wl,-rpath&＃61;thirdparty/lib/$ ldd libbar.so | grep foo libfoo.so &＃61;> thirdparty/lib/libfoo.so (0x00007f8319965000)

注意最后的 -Wr,-rpath 指定的是动态库的路径。看似和 -L 重复&＃xff0c;实际不然。-L 指定的是编译时链接的 libfoo.so 路径&＃xff0c;而 -Wl,-rpath 指定的是(libbar.so)运行时链接的 libfoo.so 路径。这里指定的是相对路径。

因此如果我们安装 libbar.so 到全局又不影响全局的 libfoo.so&＃xff0c;比如安装到 /usr/lib64 下面&＃xff1a;

$ sudo cp libbar.so /usr/lib64

我们继续编译 libbar.so 的使用程序&＃xff1a;

$ g&＃43;&＃43; main.cc -lbar$ ldd a.out | grep foo libfoo.so &＃61;> thirdparty/lib/libfoo.so (0x00007f5d3d79f000)$ ldd a.out | grep bar libbar.so &＃61;> /usr/lib64/libbar.so (0x00007fed07e78000)$ ls /usr/lib64/libfoo.so /usr/lib64/libfoo.so

这样想发布依赖高版本 libfoo.so 的 libbar.so 时&＃xff0c;用户只需要在编译和运行时&＃xff0c;相对路径 thirdparty/lib 下面有高版本 libfoo.so 就行了&＃xff0c;无需覆盖全局路径下的低版本 libfoo.so。

注意如果换个路径运行 a.out&＃xff0c;由于 rpath 指定的是相对路径&＃xff0c;此时会找不到 libfoo.so。

所以 rpath 指定绝对路径的做法也是比较常见的&＃xff0c;比如编译 libbar.so 时将 libfoo.so 置于不会冲突的系统目录&＃xff1a;

$ sudo mkdir -p /usr/lib64/foo-1.1$ sudo cp thirdparty/lib/libfoo.so /usr/lib64/foo-1.1$ g&＃43;&＃43; -o libbar.so -fPIC -shared src/bar.cc \ -I include/ -I thirdparty/include/ \ -L /usr/lib64/foo-1.1 -lfoo -Wl,-rpath&＃61;/usr/lib64/foo-1.1 $ ldd libbar.so | grep foo libfoo.so &＃61;> /usr/lib64/foo-1.1/libfoo.so (0x00007f83df270000)

那么用户部署时&＃xff0c;只需要将 libfoo.so 放置在 /usr/lib64/foo-1.1 下面就行&＃xff0c;这里的 1.1 用于标识版本号。由于该目录并不会被自动连接&＃xff0c;从而防止了其他程序自动链接到这个版本的 libfoo.so。

4

回到现代&＃xff0c;使用 CMake

但凡稍有规模的程序&＃xff0c;直接使用 GCC 编译来构建项目是难以维护的。即使有了 Makefile&＃xff0c;管理和维护起来还是相对麻烦。C&＃43;&＃43; 缺乏类似 Maven 那样的构建系统&＃xff0c;但退而求其次&＃xff0c;CMake 已经成为了事实上的 C&＃43;&＃43; 构建通用解决方案。

以一个极简的 CMakeLists.txt 为例&＃xff0c;将 rpath 指定为相对路径&＃xff1a;

cmake_minimum_required(VERSION 2.8.12)project(Bar CXX)# 设置 find_path/find_library 查找的根目录&＃xff0c;默认会从 include 以及 lib 子目录查找set(CMAKE_PREFIX_PATH "${PROJECT_SOURCE_DIR}/thirdparty")find_path(FOO_INCLUDE_DIR NAMES foo.h)find_library(FOO_LIB NAMES libfoo.so)add_library(bar SHARED src/bar.cc)include_directories(./include ${FOO_INCLUDE_DIR})target_link_libraries(bar ${FOO_LIB})# 设置 rpath&＃xff0c;这里是绝对路径set(CMAKE_INSTALL_RPATH "${PROJECT_SOURCE_DIR}/thirdparty/lib")# 安装到 lib 子目录&＃xff0c;该相对路径是相对 CMAKE_INSTALL_PREFIX 而言的install(TARGETS bar LIBRARY DESTINATION lib)

说是回到现代&＃xff0c;我这个 CMake 还是老式的风格&＃xff0c;现代 CMake 又是另一个话题了&＃xff0c;不熟悉 CMake 的话&＃xff0c;可以直接从现代 CMake 学起(版本至少 3.1)。

当前目录层次&＃xff1a;

.├── CMakeLists.txt├── include│ └── bar.h├── main.cc├── src│ └── bar.cc└── thirdparty ├── include │ └── foo.h └── lib        └── libfoo.so

使用 CMake 构建项目&＃xff1a;

$ mkdir _builds && cd _builds/$ cmake .. -DCMAKE_INSTALL_PREFIX&＃61;$PWD/..$ make$ make install

完成后的目录层次(忽略中间目录)&＃xff1a;

.├── CMakeLists.txt├── include│ └── bar.h├── lib│ └── libbar.so├── main.cc├── src│ └── bar.cc└── thirdparty ├── include │ └── foo.h └── lib └── libfoo.so

类似地&＃xff0c;为了部署的话&＃xff0c;可以将 libfoo.so 部署到系统目录 /usr/lib64 的子目录。

也可以修改成相对路径&＃xff1a;

set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS} -Wl,-rpath,&＃39;$ORIGIN/thirdparty&＃39;)

其中 $ORIGIN 会被替换成动态库所处的绝对路径&＃xff0c;也就是说只要 libfoo.so 处于 libbar.so 同级目录 thirdparty 下面&＃xff0c;如下图所示&＃xff1a;

.
├── libbar.so
└── thirdparty
└── libfoo.so

之后 libbar.so 就会链接到 thirdparty/libfoo.so&＃xff0c;并且都是绝对路径。(这里指的是查找 libfoo.so 的路径不随当前操作目录而改变)

5

Linux 动态库查找路径

最后一节&＃xff0c;以理论来结尾。前文侧重实践&＃xff0c;有了实践作为基础&＃xff0c;回过头来看原理就更有体会了。

一个典型的 C/C&＃43;&＃43; 程序的构建流程是&＃xff1a;预处理&＃xff0c;汇编&＃xff0c;编译&＃xff0c;链接。而执行链接的程序其实是 ld&＃xff0c;通常编译器比如 GCC 都会自动调用 ld 去进行链接&＃xff0c;用户不必关注其中的细节。而 ld 查找动态库的顺序是&＃xff1a;

1. rpath 指定的目录&＃xff1b;

2. 环境变量 LD_LIBRARY_PATH 指定的目录&＃xff1b;

3. runpath 指定的目录&＃xff1b;

4. /etc/ld.so.cache 缓存文件&＃xff0c;通常包含 /etc/ld.so.conf 文件编译出的二进制列表(比如 CentOS 上&＃xff0c;该文件会使用 include 从而使用 ld.so.conf.d 目录下面所有的 *.conf 文件&＃xff0c;这些都会缓存在 ld.so.cache 中)

5. 系统默认路径&＃xff0c;比如 /lib&＃xff0c;/usr/lib。

在编译时若使用 -z nodefaultlib 选项&＃xff0c;则会跳过 4 和 5。至于 runpath&＃xff0c;和 rpath 类似&＃xff0c;都是二进制(ELF 格式)文件的动态 section 属性(分别为 DT_RUNPATH 和 DT_RPATH)&＃xff0c;唯一区别就是是否优先于 LD_LIBRARY_PATH 来查找。这里就不详述了。

6

总结

至此&＃xff0c;读者对如何编译/部署动态库&＃xff0c;以及动态库之间的依赖关系应该有了一定的认识。

相比而言&＃xff0c;静态链接部署简单&＃xff0c;像 Golang 这种语言直接全部静态链接&＃xff0c;因此受到了不少用户的青睐&＃xff0c;而且静态链接占用体积大的问题在现代几乎不再是需要特别考虑的问题。

但动态库有动态库的好处&＃xff0c;比如在大型项目有多个组件依赖时&＃xff0c;如果全部静态链接&＃xff0c;则每次修改依赖的模块&＃xff0c;都要将主模块重新编译一遍&＃xff0c;对于 C&＃43;&＃43; 这种编译速度可能会非常耗时的语言是灾难性的。

另外&＃xff0c;提供插件给解释型语言(比如 Python 和 PHP)来调用时&＃xff0c;动态库是必须的&＃xff0c;解释器可以动态加载动态库。如果使用静态链接&＃xff0c;恐怕没人愿意每换一个插件就要将解释器重新编译一遍。

360云计算

由360云平台团队打造的技术分享公众号&＃xff0c;内容涉及数据库、大数据、微服务、容器、AIOps、IoT等众多技术领域&＃xff0c;通过夯实的技术积累和丰富的一线实战经验&＃xff0c;为你带来最有料的技术分享