使用 RPATH 构建 OpenSSL? [英] Build OpenSSL with RPATH?

问题描述

我有 Ubuntu 14.04.它带有 openssl 1.0.1f.我想安装另一个openssl版本(1.0.2)，我想自己编译它.

I have Ubuntu 14.04. It came with openssl 1.0.1f. I want to install another openssl version (1.0.2) and I want to compile it by myself.

我是这样配置的:

LDFLAGS='-Wl,--export-dynamic -L/home/myhome/programs/openssl/i/lib 
-L/home/myhome/programs/zlib/i/lib'

CPPFLAGS='-I/home/myhome/programs/openssl/i/include 
-I/home/myhome/programs/zlib/i/include'

./config --prefix=/home/myhome/programs/openssl/i 
zlib-dynamic shared --with-zlib-lib=/home/myhome/programs/zlib/i/lib 
--with-zlib-include=/home/myhome/programs/zlib/i/include

make 

make install

安装后，当我用ldd openssl检查二进制文件时，结果是:

After install, when i check the binary with ldd openssl, and the result is:

...
libssl.so.1.0.0 => /home/myhome/programs/openssl/i/lib/libssl.so.1.0.0 (0x00007f91138c0000)
libcrypto.so.1.0.0 => /home/myhome/programs/openssl/i/lib/libcrypto.so.1.0.0 (0x00007f9113479000)
...

看起来不错.但是当我查看ldd libssl.so时，结果是:

which looks fine. But when I check ldd libssl.so, the result is:

...
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fac70930000)
...

它仍然使用系统版本的libcrypto.我尝试了不同的方法构建，但结果始终保持不变.

It still uses the system version of libcrypto. I tried different ways to build, but result is always stays the same.

我的问题是如何以某种方式配置构建，它可以硬编码共享库的所有二进制和库依赖项，而无需使用 LD_LIBRARY_PATH 或类似的东西.

My question is how to configure the build in a way, that it can hardcode all binary and library dependencies of shared libraries without using LD_LIBRARY_PATH, or anything like that.

推荐答案

现在是 2019 年，OpenSSL 可能已经发生了一些变化，所以我将描述我是如何解决这个问题的，偶尔其他人可能会发现它有用(并且以防我需要再次为自己找出这个命令行参数).

It's 2019, and OpenSSL might have changed a little, so I'll describe how I solved this, on the odd chance someone else might find it useful (and in case I ever need to figure out this command line argument again for myself).

我想以交叉编译的方式构建 OpenSSL(使用 docker 容器，因为我正在处理非常旧的 Linux 内核但现代编译器)，但提供不依赖于绝对路径的安装，就像正如我在 jww 的回答中所描述的那样，使用 rpath 就是这种情况.

I wanted to build OpenSSL in a way that would cross-compile (using docker containers, because I'm dealing with freakishly old Linux kernels yet modern compilers), yet provide an install that did not depend upon absolute paths, as would be the case using rpath as I've seen described in jww's answer here.

我发现我可以通过这种方式运行 OpenSSL 的配置脚本来实现我想要的(从 bash 提示):

I found I can run OpenSSL's Configure script in this way to achieve what I want (from a bash prompt):

./Configure linux-x86 zlib shared -Wl,-rpath=\$$ORIGIN/../lib

这会导致生成的 Makefile 以某种方式构建可执行文件和共享对象，从而使加载程序首先在./../lib"(相对于可执行文件或共享对象的位置)中查找依赖项，然后在 LD_LIBRARY_PATH 等中.那个古怪的字符组合正确地通过了 bash 命令行、脚本和 Makefile 组合，以根据链接器的要求($ORIGIN/../lib)创建 -rpath 参数.

This causes the generated Makefile to build the executables and the shared objects in a way that makes the loader look for dependencies first in "./../lib" (relative to the location of the executable or the shared object), then in the LD_LIBRARY_PATH, etc. That wacky combination of characters properly gets past the bash command line, the script, and the Makefile combinations to create the -rpath argument according to how the linker requires it ($ORIGIN/../lib).

(显然，选择对您有意义的其他选项.这里的关键在于 -Wl,-rpath=\$$ORIGIN/../lib 选项).

(Obviously, choose the other options that make sense to you.. the key here is in the -Wl,-rpath=\$$ORIGIN/../lib option).

因此，如果我使用前缀--prefix=/opt/spiffness"调用 ./Configure，然后决定将spiffness"重命名为guttersnipe"，则一切仍然正常，因为路径是相对的而不是绝对的.

So, if I called ./Configure with a prefix of '--prefix=/opt/spiffness', and later decided to rename 'spiffness' to 'guttersnipe', everything will still work correctly, since the paths are relative rather than absolute.

我没有尝试将参数传递到 ./config 以查看它是否在那里工作，因为我的用例有点特殊，但我怀疑它会.如果我不尝试使用 dockerized 容器进行交叉编译，我会更喜欢使用 ./config 到 ./Configure，因为它在检查当前环境以查看要创建的二进制文件类型方面做得很好.

I have not tried passing the argument into ./config to see if it works there since my use case was a bit special, but I suspect it would. If I were not attempting to cross-compile with dockerized containers, I would prefer using ./config to ./Configure, as it does a decent enough job of examining the current environment to see what kind of binaries to create.

我希望这是有用的.

这篇关于使用 RPATH 构建 OpenSSL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！