You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Followup to #5219 and #11746. Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build rustc dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path).
If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically (#11253).
If you've got a rust installed locally in /usr/local, then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 rustc, this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Rust now builds and passes tests with --disable-rpath. This feature could be disabled by default or completely removed, with LD_LIBRARY_PATH as a suggestion for those who want to use a dynamically linked rustc in their home directory on *nix.
Activity
alexcrichton commentedon Jan 23, 2014
I think that the largest difficulty for this is that we build
rustc
dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path).If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
brson commentedon Jan 23, 2014
If we defaulted to static linking then there would it would be easier to justify making people use LD_LIBRARY_PATH when they opt in to dylibs.
alexcrichton commentedon Jan 23, 2014
The only consideration that I have about static linking is that you'll install 5 copies of
librustc
(as opposed to 3):with static linking
without static linking
That being said, our distributions are already pretty big, so maybe this isn't much of a concern?
I agree though that if we statically linked everything then we could easily take this route of action
jhasse commentedon Jan 23, 2014
IMO this is a concern.
What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically (#11253).
alexcrichton commentedon Jan 23, 2014
Another use case for this came up on IRC.
If you've got a rust installed locally in
/usr/local
, then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1rustc
, this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).pnkfelix commentedon Jan 30, 2014
Accepted for 1.0, P-backcompat-lang.
thestinger commentedon Mar 7, 2014
Rust now builds and passes tests with
--disable-rpath
. This feature could be disabled by default or completely removed, withLD_LIBRARY_PATH
as a suggestion for those who want to use a dynamically linkedrustc
in their home directory on *nix.auto merge of #14832 : alexcrichton/rust/no-rpath, r=brson
Auto merge of rust-lang#11747 - flip1995:rustup, r=flip1995