如何使用相对rpath编译OpenSSL

时间:2012-02-22 17:15:41

标签: makefile openssl rpath

我一直在尝试使用以下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相关的问题并尝试了各种转义和引用技巧但到目前为止没有任何工作!

5 个答案:

答案 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。事实上,我过去没有运气,因为事情会被覆盖,而CFLAGSLDFLAGS等其他内容会被忽略。

另请参阅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/使逃避噩梦。