-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
Currently when building a staticlib
, the resulting static library contains a copy of all of std and various other things. This makes the minimum size of a staticlib
something around 20MB with Rust 1.69 on Linux x86-64, which is not exactly small.
This is currently a blocker for GStreamer to ship (static) plugins written in Rust on Android/iOS (and elsewhere) as that adds up to a couple of 100MB.
While this can in theory be solved after the fact by repackaging the ar
archives and having a single copy of std, this seems like something that could be useful to solve in general.
An obvious solution here would be having some kind of "slim" staticlib
variant which does not include a copy of everything every time but instead require the final linking step (to an executable or shared library) to list a static libstd.a
(among other things). This would also require to ship a static version of std together with the already existing shared version. --print native-static-libs
would then print all those other static libraries too.
Activity
workingjubilee commentedon May 16, 2023
If at all possible it would be preferable to have this somehow incorporated in the default way of building staticlibs and instead have "fat" staticlibs be the "new" configurable option for people who still need that variation.
sdroege commentedon May 16, 2023
While I agree that it would be a better default, I don't think it's a good idea to change that default at this point. It's going to break existing usage that assumes that
staticlibs
are (mostly) self-contained.bjorn3 commentedon May 16, 2023
A couple of days ago my PR #106560 got merged. By combining
-Z staticlib-allow-rdylib-deps
with-Z staticlib-prefer-dynamic
, libstd will be dynamically linked and--print native-static-libs
will tell you how to dynamically link against libstd. This does not however enable statically linking libstd. I'm not sure what the best way to add that is though.The
staticlib
just likecdylib
is not supposed to export any symbols outside of those that are#[no_mangle]
, which would makelibstd.a
impossible. Currently it does export all symbols as there is no way to indicate that a symbol shouldn't be exported from an archive (forcdylib
we have control over the linker, forstaticlib
we don't). This needs to be fixed to allow multiple ruststaticlib
's to be linked into the same executable or dynamic library without getting symbol conflicts. (#104707) Maybe one option would be to have something like arstaticlib
crate type which can bundle multiple crates and can be statically linked (that is it is tostaticlib
whatdylib
is tocdylib
) and then additionally ship libstd asrstaticlib
.--gc-sections
when linking a Rust staticlib into another target mesonbuild/meson#11792