CMake中INSTALL_RPATH与BUILD_RPATH问
1. RPATH和RUNPATH区别
RPATH和RUNPATH都可以用来在运行时搜索动态库,下面用一个简单的例子说明二者的区别。
example:一个小工程中,有1个头文件和3个源文件。
头文件sub.h中的内容如下:
#ifndef TESTRPATH_SUB_H
#define TESTRPATH_SUB_H
void f1(void);
void f2(void);
#endif
源文件a.c中的内容如下:
#include "sub.h"
void f1(void) {
}
源文件b.c中的内容如下:
#include "sub.h"
void f2(void) {
f1();
}
源文件main.c中的内容如下:
#include "sub.h"
int main(void) {
f2();
}
测试:
- 在Ubuntu16.04 + gcc5.4中编译,命令及结果如下:
madengyun@intellif-B250-HD3:~/TestRpath$ gcc a.c -fPIC -shared -o liba.so
madengyun@intellif-B250-HD3:~/TestRpath$ gcc b.c -fPIC -shared -L$PWD -la -o libb.so
madengyun@intellif-B250-HD3:~/TestRpath$ gcc main.c -L$PWD -Wl,-rpath,$PWD -lb
madengyun@intellif-B250-HD3:~/TestRpath$ ldd a.out
linux-vdso.so.1 => (0x00007ffe00568000)
libb.so => /home/madengyun/TestRpath/libb.so (0x00007f8baa94c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8baa582000)
liba.so => /home/madengyun/TestRpath/liba.so (0x00007f8baa380000)
- 在Ubuntu18.10 + gcc5.4中编译,命令及结果如下:
mdy@mdy-pc:~/TestRpath$ gcc a.c -fPIC -shared -o liba.so
mdy@mdy-pc:~/TestRpath$ gcc b.c -fPIC -shared -L$PWD -la -o libb.so
mdy@mdy-pc:~/TestRpath$ gcc main.c -L$PWD -Wl,-rpath,$PWD -lb
mdy@mdy-pc:~/TestRpath$ ldd a.out
linux-vdso.so.1 (0x00007fff635a1000)
libb.so => /home/mdy/TestRpath/libb.so (0x00007f59d326f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f59d2e7e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f59d3673000)
liba.so => not found
在Ubuntu18.10中编译生成的app,ldd显示找不到liba.so。
但其实liba.so和libb.so在同一目录下,ldd可以找到libb.so,却找不到liba.so。
用readelf -d分析两种环境下生成的app:
可以看出Ubuntu16.10中生成的是RPATH,而Ubuntu18.10中生成的是RUNPATH。
简单地说,在搜索app的间接依赖库时,RPATH起作用,但RUNPATH不起作用。
在使用RUNPATH的情况下,很可能还要再配合LD_LIBRARY_PATH一块使用。
所以:最好使用RPATH,这样就不用依赖LD_LIBRARY_PATH了
但是,如何控制生成RPATH还是RUNPATH?
链接时使用–enable-new-dtags可以固定生成RUNPATH,使用–disable-new-dtags可以固定生成RPATH。
set_target_properties(XXX LINK_FLAGS "-Wl,--disable-new-dtags")
2. CMake build之后消除RPATH
CMake对于RPATH的管理也非常人性化:
- 官方说法是当动态库的编译也和执行档在同级目录下的时候,CMake会自动给执行档加入适当的RPATH
- 具体可以通过readelf -d executable来查看相关的RPATH路径(target_add_library就会增加RPATH到TARGET上)。
所以有的时候用QMake编译之后还得手动加一把LD_LIBRARY_PATH,而用CMake编译之后,直接执行执行档就可以了。
CMake搜索库的顺序如下:
RPATH: 写在elf文件中
LD_LIBRARY_PATH:环境变量
RUNPATH:写在elf文件中
ldconfig的缓存:配置/etc/ld.conf*可改变
默认的/lib, /usr/lib
CMake在默认情况下是会给你的exe加入相关RPATH的,这个时候可能会有不想要相关RPATH的需求,仔细查阅寻找之后发现,CMake里面维护了3个比较重要的RPATH变量,即:
- CMAKE_SKIP_RPATH
- CMAKE_SKIP_BUILD_RPATH
- CMKAE_INSTALL_RPATH
set(CMAKE_SKIP_RPATH TRUE)
set(CMAKE_SKIP_BUILD_RPATH TRUE)
set(CMAKE_SKIP_INSTALL_RPATH TRUE)
构建期间和安装期间不允许CMake给你加入相关RPATH, 想要追加RPATH, 只需要对这三个变量设置成FALSE。 不过,默认CMake在帮你编译之后,如果你使用了相关动态库,它会在相应的exec文件中增加你相关生成动态库的路径,这样当你每次去执行的时候你不需要每次都LD_LIBRARY_PATH就可以正常运行。
可以看到,当前myexe中的RPATH字段有一个Library rpath,其中指定了你生成相应动态库target的目标路径
readelf -d myexe
或者
来查看当前executable已经寻找到了哪些动态库。
ldd -r myexe
因为目前的RPATH都是写的绝对路径
所以移动相关shared_lib库的路径,这个时候你再去运行myexe,你就会发现它已经找不到相关的动态库了。
2.1 make install下CMake是如何处理RPATH的?
CMake为了方便用户的安装,默认在make install之后会自动remove删除掉相关的RPATH,这个时候你再去查看exe的RPATH,已经发现没有这个字段了。
因此,当每次make install之后,我们进入到安装路径下执行相关exe的时候,就会发现此时的exe已经找不到相关的库路径了,因为它的RPATH已经被CMake给去除了。
2.2 如何让CMake能够在install的过程中写入相关RPATH,并且该RPATH不能使当初build的时候的RPATH呢?
答案就是CMAKE_INSTALL_RPATH
这个全局变量和INSTALL_RPATH
这个target属性。
CMake在安装的过程会有一个和configure一样的安装路径,CMAKE_INSTALL_PREFIX
(configure下是–prefix,当然也可以用shell下的全局变量DESTDIR
);
这个时候它会把你的安装文件安装到你prefix下的相对路径下,因此当我们希望在make install的时候,比如当前的share_lib在lib目录下,我们希望安装之后的RPATH
可以自动找到它,我们就可以这么写:
set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)
# 需要注意的是,这个变量是全局变量,意味着你所有的target的RPATH都会在install的时候被写成这个(包括myexe和不需要RPATH的share_lib)
set_target_properties(${PROJECT_NAME} PROPERTIES
INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib"
LINK_FLAGS "-Wl,--disable-new-dtags")
这样就可以保证只针对当前的target进行make install的时候RPATH的写入了
2.3 如何让RPATH寻找相对路径
set_target_properties(${PROJECT_NAME} PROPERTIES
INSTALL_RPATH "$ORIGIN/../lib"
LINK_FLAGS "-Wl,--disable-new-dtags")
在GCC中有个变量可以获得程序当前路径,即:
$ORIGIN
当希望使用相对位置寻找.so文件,就需要利用$ORIGIN
设置RPATH
set_target_properties(${PROJECT_NAME} PROPERTIES
INSTALL_RPATH "$ORIGIN/../lib;/other/lib/path"
LINK_FLAGS "-Wl,--disable-new-dtags")
多个路径之间使用冒号“:”隔开