(Capturing some investigation I dumped into IRC)
On Wed, 27 Jul 2016 at 09:54 Ximin Luo <infini...@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
