Stream: general

Topic: Why is rpath relative?


RalfJ (Feb 12 2019 at 09:21, on Zulip):

In https://github.com/rust-lang/rust/issues/58343 I am describing some issue I am having with -C rpath. The biggest problem is that it is always relative, meaning that if the binary is moved, the rpath breaks. This is a problem because even cargo build will move the binary, meaning that rpath is basically useless when using cargo. (The absolute fallback path doesn't help at all, it points to a directory that does not even exist on my system.) Do you know why the rpath is relative?

RalfJ (Feb 12 2019 at 09:21, on Zulip):

I guess an alternative would be to tweak cargo build and cargo install such that they always create the binary in the target directory instead of moving it after it got built.

Jake Goulding (Feb 12 2019 at 13:51, on Zulip):

AIUI, rpath is intended to be relative to the binary so that you can ship around files like mypackage/bin/program and mypackage/lib/myliband it will just find the right thing

Jake Goulding (Feb 12 2019 at 13:51, on Zulip):

https://stackoverflow.com/questions/40602708/linking-rust-application-with-a-dynamic-library-not-in-the-runtime-linker-search

Jake Goulding (Feb 12 2019 at 13:52, on Zulip):

e.g. cargo rustc -- -C link-args='-Wl,-rpath,$ORIGIN/../../../library/'

RalfJ (Feb 12 2019 at 13:53, on Zulip):

ah, -C link-args sounds great

RalfJ (Feb 12 2019 at 13:53, on Zulip):

I can just add my absolute path there...

Last update: Nov 21 2019 at 23:45UTC