[Pkg-rust-maintainers] Issues with dylibs outside LD_LIBRARY_PATH

[Luca Bruno]

On Saturday 28 February 2015 11:18:59 Angus Lees wrote:
> Just before I forget what I've managed to unravel:
> 
> I'm trying to compile cargo using rustc from our rustc.deb.

Is alpha2 actualy buildable with that rustc or are we still hitting #1223?
https://github.com/rust-lang/cargo/issues/1223

> The first issue I've hit is that the build.rs commands fail because rustc 
> isn't using
> -C rpath by default and cargo builds the build scripts with -C
> prefer_dynamic.
> 
> I think that the -C prefer_dynamic bit might be a cargo bug in this
> situation, but the issue is still a valid one. 

I suspect the same. Can you please share the build log or the source package, 
just to get a better idea?
I haven't checked the details, but I think we should probably ask them to 
build cargo with a [profile.dev] containing:
"""
rpath = true
# or
lto = true
"""
and wait for #1368 to land:
https://github.com/rust-lang/cargo/pull/1368

Does the above work for you? If so, can you please open a bug upstream to 
discuss this? Also, we would probably need a way to set/override build 
profiles system-wide.

> <emphasis>
> So long as we have _any_ use-case for dylibs, I think we need to either
> patch rustc to enable -C rpath by default, or move the dylibs back into
> LD_LIBRARY_PATH (and thus no longer require rpath).
> </emphasis>
> 
> My preference is on the latter.  One day we will have library ABI
> compatibility and need to split out a "rust-libstd" package from rustc.deb,
> so we're going to need some major library upheaval in the not-too-distant
> future.  I suggest we do the simplest thing now (move the dylibs back into
> standard lib dirs) and deal with installing multiple library versions later
> - once we know more about exactly what that will require.

I'm also not a great fan of rpath. Upstream suggests static linking, but still 
they ship several .so and many stuff subtly depends on that.

However, it may makes sense to keep hiding the .so away for now and see how 
many stuff breaks. These are genuine bugs in the "build statically" strategy 
upstream is suggesting, so they should be fixed now. 

> Of course from a packaging pov, any _package_ that shipped dylibs (compiler
> plugins?) would need a strong dependency on the rustc version 

I expect compiler plugins to be tightly linked to rustc version anyway.

> Cargo's use of dylibs
> as a temporary step in the build process (for build.rs) seems like
> something we should support, however.

I think this specific case is something to be fixed in cargo.

The bigger point is still open for discussion, though.

Ciao, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG Key ID: 0x4F3BBEBF
  `-     http://www.debian.org 	| Debian GNU/Linux Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150302/0e64dd00/attachment.sig>