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

Move metadata out of dylibs #23366

Open
vadimcn opened this issue Mar 14, 2015 · 10 comments · May be fixed by #120855
Open

Move metadata out of dylibs #23366

vadimcn opened this issue Mar 14, 2015 · 10 comments · May be fixed by #120855
Labels
A-metadata Area: Crate metadata C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@vadimcn
Copy link
Contributor

vadimcn commented Mar 14, 2015

Crate metadata constitute a significant proportion of Rust dylibs. It's only needed for compilation; otherwise it just bloats up the size of Rust programs, and, unlike debug info, can't even be easily stripped.
In the case of dylibs, we could move metadata out into a companion file (say, <library>.rsmd), which developers may choose to not distribute if linking to the library is not expected (for example, Rust's own stage0 binaries).
I think this approach would be very congruent with Rust's philosophy of zero cost abstractions. The only downside I can see, is that distribution of dylibs as libraries would become slightly less convenient as there would be two files instead of one.

@nagisa
Copy link
Member

nagisa commented Mar 14, 2015

Is is actually pretty easy to strip them. The incantation is something similar to strip -R __note.rustc for apples and strip -R .note.rustc for everything else.

@vadimcn
Copy link
Contributor Author

vadimcn commented Mar 15, 2015

Is is actually pretty easy to strip them.

Ah, that's nice to know!
Still, one has to jump through extra hoops to get the optimal binary. This seems... sub-optimal.
People are already asking why Rust executables are so much bigger than C++'s. Soon they'll notice that dylibs are larger too.

@sanxiyn sanxiyn added the A-metadata Area: Crate metadata label Mar 16, 2015
@steveklabnik steveklabnik added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 6, 2016
@steveklabnik
Copy link
Member

Triage: no change, marking with enhancement, since it can be stripped.

@jonas-schievink
Copy link
Contributor

Don't cdylibs solve this?

@retep998
Copy link
Member

retep998 commented Jun 6, 2016

cdylib does solve this issue for itself, however the issue still exists for dylib for people who really want to have their Rust program depends on Rust dylibs instead of statically linking them. Also this has an impact on the size of Rust distributions, since rustc's dependencies are all in dylib form (so plugins can work correctly), while in reality they don't need any of that metadata bloat since code is compiled against the libraries in the appropriate rustlib folder.

@cuviper
Copy link
Member

cuviper commented Jul 24, 2016

Note that it's not actually easy to strip these notes according to #26764.

Another fun aspect is that systems which use .gnu_debugdata, described here, will end up duplicating the entire .note.rustc. The given procedure uses objcopy --only-keep-debug, which also preserves notes, then further strips into a mini_debuginfo file with just symbol tables and those notes. That mini_debuginfo finally gets compressed into a new .gnu_debugdata section on the original file. But it's not so "mini" when it contains all of .note.rustc.

That MiniDebuginfo procedure can probably add an exclusion, the same as it does for .gdb_index and .comment already, but it wouldn't be nice if every language had their own special exclusions here...

@cuviper
Copy link
Member

cuviper commented Aug 15, 2016

Now that #35409's 1bb1444 converted it away from an allocated note, it should be fine to be stripped.

@steveklabnik
Copy link
Member

Triage: not aware of any work on this issue.

@gilescope
Copy link
Contributor

Now that we have cargo strip can we close this?

@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

#93945 once I revive it would fix this issue.

@bjorn3 bjorn3 linked a pull request Feb 9, 2024 that will close this issue
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 9, 2024
Introduce -Zsplit-metadata option

This will split the crate metadata out of library files. Instead only the svh and a bit of extra metadata is preserved to allow for loading the right rmeta file. This significantly reduces library size. In addition it allows for cheaper checks if different library files are the same crate.

A fair amount of the complexity in this PR is to work around the fact that cargo doesn't directly support this option yet.

Fixes rust-lang#23366
Fixes rust-lang#57076

Revives rust-lang#93945
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-metadata Area: Crate metadata C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants