Skip to content

Add a "slim" staticlib variant that does not include a copy of std #111594

@sdroege

Description

@sdroege
Contributor

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

workingjubilee commented on May 16, 2023

@workingjubilee
Member

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.

added
A-linkageArea: linking into static, shared libraries and binaries
C-enhancementCategory: An issue proposing an enhancement or a PR with one.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on May 16, 2023
sdroege

sdroege commented on May 16, 2023

@sdroege
ContributorAuthor

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

bjorn3 commented on May 16, 2023

@bjorn3
Member

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 like cdylib is not supposed to export any symbols outside of those that are #[no_mangle], which would make libstd.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 (for cdylib we have control over the linker, for staticlib we don't). This needs to be fixed to allow multiple rust staticlib'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 a rstaticlib crate type which can bundle multiple crates and can be statically linked (that is it is to staticlib what dylib is to cdylib) and then additionally ship libstd as rstaticlib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @sdroege@bjorn3@workingjubilee

        Issue actions

          Add a "slim" staticlib variant that does not include a copy of std · Issue #111594 · rust-lang/rust