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

[Jordan Justen]

On 2015-02-28 03: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.A  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.A  Perhaps a
>    clearerA 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.A  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.A  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.A  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?

I take it you read over this thread that Sylvestre mentioned
previously?
http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20150119/000026.html

I think we should not recommend dynamic linking until the rust
developers do. https://github.com/rust-lang/rust/issues/10209
That includes trying to set -C rpath by default.

I think the rust developers need to design a different system for rust
libraries. Maybe that's why they have delayed recommending dynamic
linking for now.

Here's the points I don't like about including the rust libs under the
main library directories:

* Like you mention, we'd have to make all rust based packages have a
  strict version dependency on the rustc package.

* Anyone that built anything with rustc would have to rebuild if they
  upgraded their rustc package.

  Ie, hash in libfoo-hash.so means broken apps when a new minor
  version is released

* Library names installed by rust seem rather odd:
  libgraphviz-4e7c5e5c.so is a rust library? graphviz is a separate
  project, so what are people supposed to make of the rustc pacakge
  installing this to the std libs path?

  I'm sure that they had their reasons, but it really seems like they
  need to grow another scheme aside from "libfoo-hash.so is obviously
  a rust library". :) To me, a separate directory seems more
  appropriate, but

I think I saw that Gentoo and Arch install these libraries under the
standard system directories. (I take it, since this is what the rust
build does by default.) So, maybe we could reverse course and follow
them, but it seems like a bad idea.

-Jordan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150302/ec0ff824/attachment.sig>