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

[Angus Lees]

Just before I forget what I've managed to unravel:

I'm trying to compile cargo using rustc from our rustc.deb.  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.  Perhaps a clearer example
raised by
https://github.com/rust-lang/rfcs/blob/master/text/0404-change-prefer-dynamic.md
is that linking against dylibs are necessary when writing compiler plugins
(and any other form of rust plugin) so I expect we'll hit this again soon
with libregex and friends.

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

Of course from a packaging pov, any _package_ that shipped dylibs (compiler
plugins?) would need a strong dependency on the rustc version and get
complicated and we should avoid those cases for now.  Cargo's use of dylibs
as a temporary step in the build process (for build.rs) seems like
something we should support, however.

Anyone want to make the case for taking the rpath-by-default approach
instead?

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150228/327118c9/attachment.html>