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

Angus Lees gus at debian.org
Tue Mar 3 01:42:02 UTC 2015


On Mon, 2 Mar 2015 at 19:18 Jordan Justen <jljusten at gmail.com> wrote:

> 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


Yes, I did, I should have referenced it in my earlier post so you wouldn't
have to repeat some of the points below.  Sorry :/

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

Agreed, although there's a difference between "recommending" and
"supporting".  We need to support dynamic linking for cases like compiler
plugins, but we certainly want to recommend (and default to) static linking
packaged binaries wherever possible.

The choice to default to static or dynamic seems separate to where we
install the libraries, no?

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

No!  Only the packages that actually linked against the dylibs would need a
strict dependency on the rustc package.  Statically compiled packages (the
default) will ignore the dylibs and have no runtime dependency on rustc.  This
will be the same wherever we put the dylibs in the filesystem.

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

Again, no.  Only binaries built with (non-default) -C prefer-dynamic would
need to be rebuilt.  This would presumably only be done by people who had a
reason to do so, and were prepared for the implications.  The issues here
will remain the same if they do choose to build with -C prefer-dynamic -C
rpath, regardless of where we install the libraries (if we require rpath,
then rpath changes add another source of fragility).

  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 we could quite easily propose a patch to rustc to generate files
with obvious "librust-graphviz-hash.so" names or something.  Afaik there
are very few restrictions imposed by ld.so here and we just have to tell
rustc what file glob to use to find them during compiles (this is already a
define in the platform mk/cfg/* files).

I think more importantly however, as Luca points out we shouldn't be
embedding implementation language in the filename.  Any rust dylibs we
choose to make available are meant to be able to be mixed freely with other
libraries implemented in C/C++/whatever.

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


More information about the Pkg-rust-maintainers mailing list