Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sdroege opened this issue May 15, 2023 · 3 comments
Open

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

sdroege opened this issue May 15, 2023 · 3 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@sdroege
Copy link
Contributor

sdroege commented May 15, 2023

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.

@workingjubilee
Copy link
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.

@workingjubilee workingjubilee added A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 16, 2023
@sdroege
Copy link
Contributor Author

sdroege commented 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
Copy link
Member

bjorn3 commented 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 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
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants