[Pkg-rust-maintainers] On rust dylibs

[Angus Lees]

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.

I think (1) is too complex, and results in every rust package having to be
recompiled and transition unstable->testing in a single group every time a
new rustc is released.  Yuck.

(2) is basically what happens if you just naively package up rustc with a
make-install.  I actually don't think that's terrible except for the tools
that get upset by missing SONAMEs.

(3) is the safest and simplest, and I'm inclined to go that way until the
upstream plans for ABI compatibility become clearer.   The only downside
appears to be wasted disk space from the duplicated code in any statically
linked rust binaries.

(4) Seems like it doesn't actually improve the versioning problem, is
starting to diverge from what upstream are doing, and requires rpath which
limits our ability to change dylib location in the future.  Obviously I
haven't appreciated the original motivation for this approach, so feel free
to point out what I've missed ;)


I'm inclined to suggest we go with (3 - rlibs only) for now, partly because
it gives us the most freedom to move to something better when upstream also
sorts this out.

Thoughts?

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