[Pkg-rust-maintainers] Bug#832565: Bug#832565: rustc: don't embed llvm in librustc_llvm

[Angus Lees]

(Capturing some investigation I dumped into IRC)

On Wed, 27 Jul 2016 at 09:54 Ximin Luo <infinity0 at debian.org> wrote:

> librustc_llvm-xx.so is approx 30MB, taking about half the space of
> libstd-rust-xx.
> Upstream tells me that this is due to embedding pretty much all of LLVM.
>
> We should explore options to make it instead dynamically link against LLVM,
> since that is the Debian convention. (Upstream probably won't spend too
> much
> time on this.) This would reduce the size of libstd-rust-xx by about half.
>

The relevant piece of code looks like it's src/librustc_llvm/build.rs:
        let kind = if name.starts_with("LLVM") {
            "static"
        } else {
            "dylib"
        };

I suspect if we remove this block (and the following cargo:rustc-link-lib
print statement), then the linker would just find shared versions of the
LLVM libs if available.

*However:* It seems our LLVM (or upstream llvm-config?) isn't ready to help
users use dynamic libraries.  Specifically the output of `llvm-config-3.8
--libs` mentions a bunch of libraries for which we only have .a versions.

Some old-ish (2010-2012) LLVM upstream discussion supports the idea that
llvm-config needs more work before this will "just work":
- https://groups.google.com/forum/#!topic/llvm-dev/g81Hcoy0stw
- https://llvm.org/bugs/show_bug.cgi?id=3201
- http://llvm.org/viewvc/llvm-project?revision=96559&view=revision

The conclusion in the above threads seems to be that we should just ignore
llvm-config, use what we (Debian) know about the build environment, and
manually specify something like "-L/usr/lib/llvm-$v/lib -lLLVM".  This
seems an easy decision for us (and other distros with controlled build
environments), but inappropriate for Rust upstream IMO.

The discussion in/around https://github.com/rust-lang/rust/pull/27937 seems
to imply that support *does* exist in some form for dynamic linking libLLVM
(and perhaps gentoo are already using it?), but I still think we may need
some changes to Debian's LLVM packaging in addition to rustc.deb build
tweaks.  Closer analysis of this discussion needed.

I agree that we will get little prioritisation from upstream on this, as
static linking LLVM is the *right* approach when using the vendored LLVM
sources.

(The size could further be reduced by splitting dev vs runtime shared
> objects,
> but upstream don't seem to be doing this themselves yet, and any work we do
> here should definitely be consulted with them first.)
>

If you're suggesting just moving some "dev only" libstd libraries
(librustc_*.so ?) entirely to the -dev (or rustc) package, then this is an
interesting thought.  I think trying to separate run-time from dev-time
quickly becomes equivalent to breaking libstd-rust-x.y into several
separate packages and just letting shlibdeps do its thing.  That seems
quite reasonable once we have non-rustc Rust applications and
libstd-rust-x.y size is a concern.

See the discussion in https://github.com/rust-lang/rust/issues/23366 for
some related discussion on reducing the size of libstd runtime libs by
stripping the (large!) .note.rustc section.  I think this is a separate
bug/issue, but note that breaking the current symlinks and having different
link-time (libstd-rust-dev) and run-time (libstd-rust-x.y) lib files
actually results in a *larger* on-disk size for rustc users.  I don't think
this is useful to explore until we have Rust application packages whose
users might not also have rustc installed.

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