[Pkg-rust-maintainers] On rust dylibs

Sylvestre Ledru sylvestre at debian.org
Mon Feb 16 18:26:31 UTC 2015


On 16/02/2015 03:36, Angus Lees wrote:
> I'm sure you've already had this conversation in the past, so sorry
> for reopening the topic.  After thinking about this for a bit, my
> conclusions are:
>
> - dylibs (rust shared libraries) aren't ABI compatible between
> compiler releases (yet, they presumably will be one day).  And the shv
> checksum thing on libraries looks promising but isn't used by upstream
> as part of a process for introducing ABI changes.
>
> So I figure our options are:
>
> 1. Use dylibs and have a strong dependency on the specific
> compiler/stdlib version and recompile every rust package when a new
> compiler comes out.
> This probably requires patching trivial SONAME support (just
> SONAME=file name) into the rust compiler, because the various
> dpkg/lintian tools get upset when they don't find an SONAME.
>
> 2. Only use dylibs between rustc and rustdoc since those are released
> from the same source package anyway (even easier if they're all in the
> same binary package).  We have dylibs in the package, but the compiler
> defaults to rlibs (static libraries) and we put a warning somewhere
> suggesting users don't depend on dylib ABI compatibility.
> Requires the same SONAME patch as (1), or disabling the lintian/etc
> warnings.
>
> 3. Don't offer dylibs at all.  Build rustc+rustdoc statically and only
> ship rlibs.
>
> 4. Build dylibs but hide them in a subdirectory not on
> LD_LIBRARY_PATH.  This means rustc+rustdoc (and any other binary that
> uses them) needs to find them via rpath.
>
> -----
>
> If I've understood correctly, (4) is the current Debian packaging
> approach.
>
Indeed.
Luca wanted to go with (1) but as the ABI is not stable yet, we didn't
want to give false hope and expectation to packagers.

We decided to go with (4) because it was a safe compromise. We don't
remove features from Rust, we give the opportunity to developers to play
with shared libs until they are stable.
The fact that the libs are not in a public LD places make it pretty clear.

The thread is here:
http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20150119/000026.html
+ some IRC discussions.

(3) was not on the table because we see the ABI instability as something
temporary (and Rust being still in NEW)
but I am not strongly opposed to it.

Cheers,
Sylvestre





More information about the Pkg-rust-maintainers mailing list