我一直在尝试使用以下rpath编译openssl 1.0.0g:
$ORIGIN/../lib64
每次我readelf -d apps/openssl
,我都会得到以下结果,具体取决于我尝试过的变化:
\RIGIN/../lib64
RIGIN/../lib64
ORIGIN/../lib64
我想在不使用chrpath等外部工具的情况下设置我的rpath。它可能吗?我基本上会接受任何不涉及使用像chrpath这样的外部工具的东西(虽然我已经完成了)。
理想情况下,我想通过在命令行上传递选项(任何形式的-Wl,-rpath,$ORIGIN/../lib64
)来实现。
我不介意编辑生成的Makefile,这是我上次尝试过的。如果我能打印出一个愚蠢的美元符号!我尝试在BUILDENV =块下修改LIBRPATH而没有运气。到目前为止我的最好成绩:
LIBRPATH=$$'ORIGIN/../lib64 # result: /../lib64
LIBRPATH=$$$$'ORIGIN/../lib64 # result: 12345<pid>/../lib64
我已经阅读了各种与rpath相关的问题并尝试了各种转义和引用技巧但到目前为止没有任何工作!
答案 0 :(得分:7)
在你的makefile中试试:
-Wl,-rpath,${ORIGIN}/../lib64
我假设 ORIGIN 是一个shell变量。
修改强>
我只是找到了你问题的答案(更好的迟到然后永远不会): 你需要阻止make来插入变量,为此你需要使用$$(双dolar符号):
-Wl,-rpath,'$$ORIGIN/../lib64'
我知道它有效,因为我已经用我自己的应用程序测试过它,享受:)
答案 1 :(得分:2)
我走了chrpath的路。 http://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/
在openssl中反击`$$ ORIGIN``的shell扩展非常复杂。由于美元符号,它迟早会扩大。如果你真的想这样做,你就可以做到。我发现以下内容可以在Linux上使用openssl 1.0.1g。在Makefile.shared中,查找以下行:
DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"
将其替换为以下内容。这个引用中和了$
的扩展。双$$
是在makefile中获得单个美元符号的方法。
DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,'"'$$'"ORIGIN/../lib64'"
编译后:
readelf -d apps/openssl | grep RPATH
0x000000000000000f (RPATH) Library rpath: ['$ORIGIN/../lib64']
答案 2 :(得分:0)
我不介意编辑生成的Makefile,这是我上次尝试的...
我不确定您是否可以使用shell变量和相对路径进行设置。我不认为ldd
扩展了$ORIGIN
中的$ORIGIN/../lib64
。在这种情况下,我认为您需要使用ldconfig
添加 $ORIGIN/../lib64
到库搜索路径。有关详细信息,请参阅服务器故障的finding ldd search path。
由于我不确定,我还是会提供说明。您不需要更改Makefile。事实上,我过去没有运气,因为事情会被覆盖,而CFLAGS
和LDFLAGS
等其他内容会被忽略。
另请参阅Build OpenSSL with RPATH?您的问题和引用的问题是收集类似答案的不同问题(它们之间没有重复)。但它提供了OpenSSL开发者在RPATH上的地位。这是一封私人电子邮件,所以我分享了相关的细节,而不是整个信息。
如果您设法将$ORIGIN/../lib64
嵌入ELF部分并且有效,请报告回来。下面,我使用/usr/local/ssl/lib
作为我的RPATH。您应该将$ORIGIN/../lib64
替换为/usr/local/ssl/lib
。
OpenSSL支持RPATH
开箱即用的BSD目标(但不包括其他目标)。从配置:
# Unlike other OSes (like Solaris, Linux, Tru64, IRIX) BSD run-time
# linkers (tested OpenBSD, NetBSD and FreeBSD) "demand" RPATH set on
# .so objects. Apparently application RPATH is not global and does
# not apply to .so linked with other .so. Problem manifests itself
# when libssl.so fails to load libcrypto.so. One can argue that we
# should engrave this into Makefile.shared rules or into BSD-* config
# lines above. Meanwhile let's try to be cautious and pass -rpath to
# linker only when --prefix is not /usr.
if ($target =~ /^BSD\-/)
{
$shared_ldflag.=" -Wl,-rpath,\$(LIBRPATH)" if ($prefix !~ m|^/usr[/]*$|);
}
为OpenSSL 1.0.2 执行此操作的最简单方法似乎是 add it to linker flags during configuration
./config -Wl,-rpath=/usr/local/ssl/lib
您还可以编辑rpath
的配置行和硬编码。例如,我正在使用Debian x86_64。因此,我在编辑器中打开了文件Configure
,复制了linux-x86_64
,将其命名为linux-x86_64-rpath
,并进行了以下更改以添加-rpath
选项:
"linux-x86_64-rpath", "gcc:-m64 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl/lib::
-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib -ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:
${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
以上,字段2和6已更改。它们对应于OpenSSL构建系统中的$cflag
和$ldflag
。
然后,使用新配置进行配置:
$ ./Configure linux-x86_64-rpath shared no-ssl2 no-ssl3 no-comp \
--openssldir=/usr/local/ssl enable-ec_nistp_64_gcc_128
最后,在make
之后,验证设置是否卡住:
$ readelf -d ./libssl.so | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
$ readelf -d ./libcrypto.so | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
$ readelf -d ./apps/openssl | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
执行make install
后,ldd
将产生预期结果:
$ ldd /usr/local/ssl/lib/libssl.so
linux-vdso.so.1 => (0x00007ffceff6c000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007ff5eff96000)
...
$ ldd /usr/local/ssl/bin/openssl
linux-vdso.so.1 => (0x00007ffc30d3a000)
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f9e8372e000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f9e832c0000)
...
答案 3 :(得分:0)
不要问我为什么,但这在 OpenSSL 1.1.1i 中对我有用,可以解决 $ 符号问题:
HTTPS
示例:
\$\$\$$ORIGIN
或者,如果此命令行 hack 与您不一致,您可以在构建后始终按照其他人的建议使用 ./Configure linux-x86_64 '-Wl,-rpath,\$\$\$$ORIGIN'
:
chrpath
答案 4 :(得分:0)
好吧,我花了几个小时与同样的问题作斗争,并尝试了各种疯狂的逃避,有一次我多达八个 $
标志,此时我决定必须有另一种方式。
事实上,至少在 GNU ld
中似乎是这样。
不要使用 -Wl,-rpath,\\$$$\$\$\$$$\$\\\\$
或某些古神召唤怪物,只需这样做:
echo '-rpath=$ORIGIN/../lib64' > rpathorigin
./config -Wl,@$(pwd)/rpathorigin ...
我没有看到 ld.gold
记录了 @
标志,而且我不知道 lld
。但是,如果您正在使用 GCC 并且它正在调用 BFD ld
,则上述内容可能对您有用。
当然,与 origin 一起使用的实际路径应该根据需要进行自定义,我对 ./config
与 ./Configure
没有意见。但是使用响应文件技巧似乎完全避开了 shell/使逃避噩梦。