我正在修改一个与Automake / libtool文档提供的示例非常相似的项目。摘录:
Top-leve configure.ac:
LT_INIT
顶级Makefile.am:
ACLOCAL_AMFLAGS = -I m4
SUBDIRS = src doc
./src
Makefile.am:
lib_LTLIBRARIES = libname.la
libname_la_SOURCES = <my cc file list>
libname_la_LDFLAGS = -no-undefined -version-info $(GENERIC_LIBRARY_VERSION)
include_HEADERS = <my h file list>
bin_PROGRAMS = progname
progname_SOURCES = <my cc file list>
progname_LDADD = libname.la
progname_LDFLAGS = -static
在我的软件包创建软件提供的fakeroot环境中,我执行以下命令
$ autogen.sh # contains the usual calls to aclocal, libtoolize, automake, autoconf.
$ ./configure --prefix="/usr" --disable-static
$ make
...
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -g -O2 -static -o progname progname.o libname.la <-lLIBRARY_NAME list>
libtool: link: g++ -Wall -g -O2 -o progname progname.o ./.libs/libname.so <-lLIBRARY_NAME list> -Wl,-rpath -Wl,<build_dir>/src/.libs
...
$ objdump -x src/progname | grep -i rpath
RPATH <build_dir>/src/.libs
$ make install
$ objdump -x <fakeroot_dir>/usr/bin/progname | grep -i rpath
RPATH <build_dir>/src/.libs
在所有三个* .la文件中,libdir='/usr/lib'
:
我知道为/ src / progname设置了RPATH以允许在make之后直接执行。但是我的印象是在安装规则期间,libtool将删除此临时RPATH并将其替换为libdir(“/ usr / lib”,如上所述进行配置)。此外,如果libdir存在于系统的ld.so搜索路径中,现代libtool版本实际上将删除RPATH。
为什么不发生这种情况?就目前而言,临时RPATH目录存在安全风险,允许任何人从/src/.libs加载恶意libname.so。
Fedora RPath打包草案包含一些有用的建议来删除RPATH,但我更喜欢在Autotools框架内工作的答案。
答案 0 :(得分:0)
我认为这里发生的事情是libtool
因使用-static
而感到困惑 - 您想要的是默认使用libtool
时通常会发生的事情,那就是触发重新连接二进制文件,以便它删除DT_RPATH
定义。
但是,既然你告诉工具你想要一个完整的静态构建,那么它希望重新连接是不必要的,因此不会执行它。
另一方面,当您使用libtool
和-static
时,我很惊讶--disable-static
没有错误。
答案 1 :(得分:0)
告诉configure.ac
到patch生成的$(top_srcdir)/libtool
,以便-Wl,-rpath -Wl,/...
被踢出
TL;DR - 将以下 (β) 附加到 configure.ac
:
AC_MSG_RESULT([configure: removing rpath from libtool...])
sed -i.old s/'^hardcode_libdir_flag_spec.*$'/'hardcode_libdir_flag_spec="-D__LIBTOOL_IS_A_FOOL__"'/g libtool
diff -u0 libtool.old libtool