构建一个简单的（hello-world-esque）示例，使用$ ORIGIN使用ld的选项-rpath [英] Building a simple (hello-world-esque) example of using ld's option -rpath with $ORIGIN
问题描述
注意：下面是完整的工作示例。原来的问题如下：
我在使用ld的 -rpath 参数时遇到问题， $ ORIGIN 。
因为我找不到完整的示例，所以我想我会自己写一个，以便我和其他人可以稍后使用它。一旦我得到它的工作，我会整理它。
我，但我认为我的帖子有点混乱。示例项目生成一个共享库和一个链接到所述库的可执行文件。
它非常小（3个文件，22行包含buildscript） 。
您可以从此处下载该项目
文件结构（构建之前）：
-
项目/
-
src /
-
foo.cpp -
main.cpp
-
-
make.sh
-
project / src / foo.cpp
int foo（）
{return 3; }
从 文件结构（建立后）： 目前，这只有部分工作。 检查 AFAICT 我试过 注意：我使用 有人知道为什么这不起作用吗？ （我宁愿有 问题大部分存在：名称中的 （你的rpath也是错的，想一想：从shell中，如果你当前在你的可执行文件所在的目录中，你将如何到达你的库所在的目录？在这里，你需要 如果您将对象构建为 更改链接行为图书馆显式设置你的图书馆的SONAME只是 修复rpath： 运行 （缺少任何 Note: Full working example now below. Original question follows: I'm having problems using ld's I asked about this before, but I think my post was a bit confusing. The example project builds one shared library and one executable that links to said library. File structure (before building):
From the File structure (after building): Currently, this only partly works. Inspecting AFAICT the I have tried Note: I'm using Does anyone know why this isn't working? (I'd rather have There's most of your problem: the (Your rpath is wrong too. Think about it: from the shell, if you were currently in the directory where your executable is, how would you get to the directory where your library is? Here, you'd need to If you built your object as Change the link line for the library to explicitly set the SONAME for your library to just Fix the rpath: It's useful to run (the lack of any
这篇关于构建一个简单的（hello-world-esque）示例，使用$ ORIGIN使用ld的选项-rpath的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！ project / src / main.cpp
$ $ p $
$ f $（$）
#include< iostream>
int main（）
{
std :: cout<< foo（）<<的std :: ENDL;
返回0;
project / make.sh code>
＃制作目录：
mkdir -p -v obj
mkdir -p -v lib
mkdir -p -v run
＃构建库：
g ++ -c -o obj / foo.o src / foo.cpp -fPIC
g ++ -shared -o lib / foo.sh obj / foo.o
＃生成可执行文件：
g ++ -c -o obj / main。 o src / main.cpp
g ++ -o run / main.run obj / main.o -Wl，-rpath，'$ ORIGIN /../../ lib'-Llib -l：foo.sh
$ / code>
项目目录下运行 b $ b make.sh （确保它是可执行的）。
项目/
src /
foo.cpp
main.cpp
obj /
foo.o
main.o
lib /
foo.so
运行/
main.run
run / main.run 现在应该加载<$
$在执行时，从任何地方执行c $ c> lib / foo.sh 问题
文件编译并链接正常，但运行时无法链接从项目（这是练习的要点）之外的任何目录。
main.run with readelf -d 显示：
0x0000000000000001（需要）共享库：[ lib / foo.sh]
0x000000000000000f（RPATH）库rpath：[$ ORIGIN /../../ lib]
看起来很接近（我宁愿 [foo.sh] 比 [lib / foo.sh] 但我会稍后解决）。
-Wl中的表示 $ ORIGIN ，-rpath，'$ ORIGIN /../../ lib' project / run / main.run ，所以这个rpath应该变成 project / lib 。
$ ORIGIN /..， $ ORIGIN /../ lib ， $ ORIGIN /../..， $ ORIGIN /../../ lib 无效。
-l：这需要完整的库文件名（除其他原因外，当所有函数采用相同的名称格式时，使用变量进行脚本更容易）。
或者，有谁知道有一个完整的工作示例？
[foo.sh] than [lib / foo.sh] 但我会在稍后解决） / 阻止动态链接器执行rpath magic。
cd ../ lib 。所以你的rpath应该是 $ ORIGIN /../ lib 。）
libfoo.so 并与 -Llib -lfoo ，链接器会找出你想要的，做正确的事情。但是，如果你打算使用不同寻常的命名规则，你必须提供帮助：
foo.sh ：
g ++ -shared -Wl，-soname，foo.sh -o lib / foo.sh obj / foo.o
g ++ -o run / main.run obj / main.o -Wl，-rpath，'$ ORIGIN / .. / lib'-Llib -l：foo.sh
ldd main / main.run 来查看发生了什么。在你最初的失败案例中，你会看到如下所示：
lib / foo.sh（0xNNNNNNNN）
=> / some / resolved / path 显示它没有做任何路径分辨率）。在固定情况下，您会看到如下所示的内容：
foo.sh => /your/path/to/run/../lib/foo.sh（0xNNNNNNNN）
-rpath parameter with $ORIGIN.
As I couldn't find a complete example, I thought I'd try to write one myself, so that I and others can use it later. Once I get it working I'll tidy it up.
It's very small (3 files, 22 lines incl buildscript).
You can download the project from here
project/
src/
foo.cppmain.cppmake.sh
project/src/foo.cpp
int foo()
{ return 3; }
project/src/main.cpp
int foo();
#include <iostream>
int main()
{
std::cout << foo() << std::endl;
return 0;
}
project/make.sh
# Make directories:
mkdir -p -v obj
mkdir -p -v lib
mkdir -p -v run
# Build the library:
g++ -c -o obj/foo.o src/foo.cpp -fPIC
g++ -shared -o lib/foo.sh obj/foo.o
# Build the executable:
g++ -c -o obj/main.o src/main.cpp
g++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../../lib' -Llib -l:foo.sh
project directory, run make.sh (make sure it's executable).
project/
src/
foo.cppmain.cppobj/
foo.omain.olib/
foo.sorun/
main.runmake.sh
run/main.run should now load lib/foo.sh on execution, from anywhere.Problems
The files compile and link OK, but it fails to link when run from any directory except project (which is the point of the exercise).main.run with readelf -d shows:
0x0000000000000001 (NEEDED) Shared library: [lib/foo.sh]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../../lib]
Which looks close (I'd rather have [foo.sh] than [lib/foo.sh] but I'll fix that later).$ORIGIN in -Wl,-rpath,'$ORIGIN/../../lib' means project/run/main.run so this rpath should become project/lib.$ORIGIN/.., $ORIGIN/../lib, $ORIGIN/../.., $ORIGIN/../../lib to no avail.-l: which requires the complete library filename (amongst other reasons, it's easier to script with variables when all functions take the same name format).
Or alternately, does anyone have or know of a complete working example?
[foo.sh] than [lib/foo.sh] but I'll fix that later)./ in the name stops the dynamic linker from doing the rpath magic.cd ../lib. So your rpath should be $ORIGIN/../lib.)libfoo.so and linked with -Llib -lfoo, the linker would work out what you were intending, and do the right thing. But if you're going to use unusual naming conventions, you'll have to help it out:
foo.sh:g++ -shared -Wl,-soname,foo.sh -o lib/foo.sh obj/foo.og++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../lib' -Llib -l:foo.shldd main/main.run to see what's going on. In your original failing case, you'll see something like: lib/foo.sh (0xNNNNNNNN)
=> /some/resolved/path showing that it's not done any path resolution). In the fixed case, you'll see something like: foo.sh => /your/path/to/run/../lib/foo.sh (0xNNNNNNNN)
