-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use DT_RUNPATH instead of DT_RPATH for -C rpath #30378
Comments
This should probably be encoded somewhere in the Target config. |
Oh hey, there's a |
Seems to work on GNU/Linux, PR opened. My local build with I haven't tested with musl or non-Linux. One thing worth noting for the record is that |
This causes the linker to emit DT_RUNPATH instead of DT_RPATH, which fixes rust-lang#30378.
This causes the linker to emit DT_RUNPATH instead of DT_RPATH, which fixes #30378. See that bug for rationale.
This causes the linker to emit DT_RUNPATH instead of DT_RPATH, which fixes rust-lang#30378.
--enable-new-dtags is the default since Rust 1.7.0 due to rust-lang/rust#30378. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
--enable-new-dtags is the default since Rust 1.7.0 due to rust-lang/rust#30378. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
--enable-new-dtags is the default since Rust 1.7.0 due to rust-lang/rust#30378. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
DT_RUNPATH is a Linuxism. Using it whenver config.linker_is_gnu is not correct. |
@MartinHusemann a two year old closed ticket is not the correct place to discuss this. Additionally, I can't find any evidence in the glibc source that DT_RUNPATH is specific to Linux. If you have a problem related to this, can you open a new issue with
|
@MartinHusemann which specific OS (kernel + libc combination) are you noticing I guess the thing I really want is that the dynamic linker is GNU libc, not that the compile-time linker is GNU ld. But as far as I know, non-Linux kernels + GNU libc (e.g., Hurd, GNU/kFreeBSD) support DT_RUNPATH. And I think that passing ... However, musl and bionic both seem to support DT_RUNPATH. So given that Rust doesn't support the Hurd yet and GNU/kFreeBSD is basically dead, maybe it's better in practice to look for a Linux kernel, even though DT_RUNPATH isn't a kernel feature. |
Sorry, I missed the (prominent) "Closed" sign at the top. I did open a new ticket already, see #46204, let's keep further discussions there. |
Old issue, but for the record: musl treats DT_RPATH and DT_RUNPATH identically. Either is searched after LD_LIBRARY_PATH, and affects both direct and indirect dependency loading. So it doesn't matter which you use for musl targets. |
On at least GNU/Linux, and possibly on other ELF-based systems, there are two types of rpath, one using the
DT_RPATH
entry in the dynamic headers and one using theDT_RUNPATH
one. The distinction is thatDT_RPATH
takes precedence over theLD_LIBRARY_PATH
environment variable, whereasDT_RUNPATH
does not. The latter is more convenient and means that rpaths are less likely to get in your way, since you can override them.DT_RPATH
is also claimed to be deprecated by the ld.so manpage. So I think thatrustc -C rpath
should generateDT_RUNPATH
where available.glibc has supported this since at least 1999. musl 1.1.6 (January 2015) seems to honor
DT_RUNPATH
but not treat it differently. You can emit both, and the GNU dynamic linker ignoresDT_RPATH
.You can tell GNU ld to emit
DT_RUNPATH
instead ofDT_RPATH
by adding--enable-new-dtags
, probably something likeHowever, neither Apple's linker nor lld supports this, and I'm not really sure how to make this platform-conditional. Hence a bug instead of a PR.
The text was updated successfully, but these errors were encountered: