Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 07/11/2014 12:09 PM, Zoltán Tóth wrote: On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson > wrote: # Impact Installing rustc to non-default locations will result in an installation that puts some important libraries in a location the dynamic li

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 13 July 2014 00:43, Stepan Koltsov wrote: > -- want to have several versions of rust side by side to investigate problems Not true, the share object files include git revision in the name and that's what they are being looked up by, as far as I understood. So one can have: DYLD_LIBRARY_PATH

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On Wed, Jul 9, 2014 at 8:48 PM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Also, when installing Rust you don't have to man

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

I believe the thought was for when we *can't* modify things like /usr/bin, because the user isn't an administrator. Obviously if we were installing things where they were supposed to go, we wouldn't have a problem finding libraries, would we now? So no-one's proposing we dump a bunch of libraries i

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 11/07/14 03:15 PM, Alex Crichton wrote: >> LD_LIBRARY_PATH is not known about by many > > The install.sh script now recommends adding an entry to this variable > if it detects that this is necessary, so it's not *entirely* unknown. > This doesn't help, however, if it's considered a bad practice

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

> LD_LIBRARY_PATH is not known about by many The install.sh script now recommends adding an entry to this variable if it detects that this is necessary, so it's not *entirely* unknown. This doesn't help, however, if it's considered a bad practice. > 1) Link dependencies of rustc statically to it?

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson wrote: > > # Impact > > Installing rustc to non-default locations will result in an installation > that puts some important libraries in a location the dynamic linker won't > find, will need to be compensated for with LD_LIBRARY_PATH. > > This is to

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On Tue, Jul 08, 2014 at 03:57:27PM -0700, Brian Anderson wrote: So we're turning it off. The previous behavior can be restored by passing --rpath to rustc, or re-enabled for the Rust distribution itself by passing --enable-rpath to configure. Is the intent to have this --rpath and especially

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

There's a fix for make install waiting on bors right now: https://github.com/rust-lang/rust/pull/15550 Steven Fackler On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari wrote: > Brian Anderson writes: > > > Hi. > > > > Very soon now the way rustc links crates dynamically is going to > > change[1], an

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Brian Anderson writes: > Hi. > > Very soon now the way rustc links crates dynamically is going to > change[1], and it will impact the way you work with Rust in some > important cases. The TL;DR is that rustc will no longer encode RPATH > information in the binaries it produces, so the dynamic

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Other programming languages do this. C and C++ do not mandate the use of RPATH, and Rust not applying RPATH by default doesn't exclude people opting into it if they want. In this context I am also considering @executable_path and @loader_path to be 'RPATH', and in fact @loader_path is the featu

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On Wed, Jul 9, 2014 at 9:48 AM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Also, when installing Rust you don't have to man

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 7/9/14 7:42 AM, Bob Ippolito wrote: This seems like madness. No other programming language out there that I've seen requires developers to mangle these environment variables. Also, when installing Rust you don't have to mangle these environment variables, since the libraries will be placed

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On Wed, Jul 9, 2014 at 9:29 AM, Patrick Walton wrote: > On 7/9/14 7:42 AM, Bob Ippolito wrote: > >> This seems like madness. No other programming language out there that >> I've seen requires developers to mangle these environment variables. >> > > Note that rpath never worked on Windows [1], so

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 7/9/14 7:42 AM, Bob Ippolito wrote: This seems like madness. No other programming language out there that I've seen requires developers to mangle these environment variables. Note that rpath never worked on Windows [1], so it could never be a long-term solution. Patrick [1]: http://stac

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

This seems like madness. No other programming language out there that I've seen requires developers to mangle these environment variables. On Mac, if you don't want all of RPATH to be searched, you can use more specific relative paths such as @executable_path or @loader_path in the load command. If

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

It is indeed! You'll need to ensure that `/Users/ilya/Library/Local/Rust/current/lib` is in your DYLD_LIBRARY_PATH environment variable for OSX. On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko wrote: > Is the following error cause by this change? > > % rustc -v > dyld: Library not loaded: > x86

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Is the following error cause by this change? % rustc -v dyld: Library not loaded: x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc Reason: image not found Trace/BPT trap On 9 July 2014 00:

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Yes, it does. On 07/08/2014 04:41 PM, Simon Sapin wrote: On 08/07/14 23:57, Brian Anderson wrote: *Running rustc directly from the build directory will no longer work by default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath to the configure script. Does this also apply to run

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 08/07/14 23:57, Brian Anderson wrote: *Running rustc directly from the build directory will no longer work by default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath to the configure script. Does this also apply to running a (nightly) binary distribution from where the tarbal

[rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Hi. Very soon now the way rustc links crates dynamically is going to change[1], and it will impact the way you work with Rust in some important cases. The TL;DR is that rustc will no longer encode RPATH information in the binaries it produces, so the dynamic linker will be less likely to find