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

[Angus Lees]

On Tue, 3 Mar 2015 at 09:27 Luca Bruno <lucab at debian.org> wrote:

> 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


I had to go back and rebuild our rustc before I could get past the build.rs
failures, so I don't know yet ;)

I talked with upstream (huonw) a few days ago and they merged/patched HEAD
into a state that was able to build with alpha.2.  There was apparently
still some outstanding (runtime) issue, but I was unclear on the details
without experimenting with it myself.

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


lto=true seems a bit heavy-handed for a dev build, but rpath=true would
presumably work ok.

Do we need to support rustc uses without cargo?  (ie: do we need to patch
rustc platform definitions rather than cargo profiles)

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

.. and rustc plugins will always need to be dynamically linked (but the
resulting binaries that _used_ those plugins to compile don't need the
runtime dependency, so the rebuild cascade is short)

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

We should be sure to separate "build statically" from "ship static
binaries" in the conversation with upstream.  Only the latter runs into ABI
versioning issues.

Cargo's use of prefer-dynamic here (for example) _should_ be fine (and is
apparently fine for everyone other than our Debian rustc, or else it would
have been noticed earlier).  The build script is a throwaway executable
that doesn't appear in the resulting installed binaries, so ABI
compatibility is not a concern.

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

Yeah.  I'm putting together a rustc that installs into /usr/lib so I can
compare experiences.  (It will stay in a non-master branch until/unless
there's further consensus).

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