Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Stop relying on rpath #11747

Closed
brson opened this issue Jan 23, 2014 · 7 comments · Fixed by #14832
Closed

Stop relying on rpath #11747

brson opened this issue Jan 23, 2014 · 7 comments · Fixed by #14832
Assignees
@brson
Labels
A-linkage Area: linking into static, shared libraries and binaries
Milestone
1.0

Comments

@brson
Copy link
Contributor

brson commented Jan 23, 2014

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.
@brson brson mentioned this issue Jan 23, 2014
Merged
@alexcrichton
Copy link
Member

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
Copy link
Contributor Author

brson commented 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
Copy link
Member

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

  • rustdoc
  • rustc
  • rustpkg
  • rustlib/rustc.dylib
  • rustlib/rustc.so

without static linking

  • librustc.so
  • rustlib/rustc.dylib
  • rustlib/rustc.so

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
Copy link
Contributor

jhasse commented 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
Copy link
Member

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 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).

@pnkfelix
Copy link
Member

Accepted for 1.0, P-backcompat-lang.

@thestinger
Copy link
Contributor

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.

@thestinger thestinger mentioned this issue Mar 7, 2014
Closed
@alexcrichton alexcrichton mentioned this issue Jun 12, 2014
Merged
@omasanori omasanori mentioned this issue Jun 16, 2014
Closed
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jun 17, 2014
@alexcrichton
rustc: Disable rpath settings by default
a0546de 
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.

This involved a few changes to the local build system:

* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes rust-lang#11747
[breaking-change]
bors added a commit that referenced this issue Jul 8, 2014
@bors
auto merge of #14832 : alexcrichton/rust/no-rpath, r=brson
206dd91 
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.

This involved a few changes to the local build system:

* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes #11747
[breaking-change]
@taralx taralx mentioned this issue Jan 20, 2015
Closed
@alexcrichton alexcrichton mentioned this issue Nov 20, 2015
Closed
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 2, 2023
@bors
Auto merge of rust-lang#11747 - flip1995:rustup, r=flip1995
09ac14c 
Rustup

r? `@ghost`

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brson brson

Labels
A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

rustc: Disable rpath settings by default alexcrichton/rust
5 participants
@alexcrichton @jhasse @brson @pnkfelix @thestinger