Skip to content

Move metadata out of dylibs #23366

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

Closed
vadimcn opened this issue Mar 14, 2015 · 10 comments · Fixed by #137535
Closed

Move metadata out of dylibs #23366

vadimcn opened this issue Mar 14, 2015 · 10 comments · Fixed by #137535
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.

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
@bors bors closed this as completed in 8c35f4a Apr 1, 2025
lnicola pushed a commit to lnicola/rust-analyzer that referenced this issue Apr 28, 2025
Introduce `-Zembed-metadata` to allow omitting full metadata from rlibs and dylibs

This is a continuation of rust-lang/rust#120855 (I was mentored by `@bjorn3` to move it forward). Most of the original code was written by bjorn3, I tried to clean it up a bit and add some documentation and tests.

This PR introduces a new unstable compiler flag called `-Zembed-metadata=[no|yes]`, with the default being `yes` (see rust-lang/rust#57076 for context). When set to `no`, rustc will only store a small metadata stub inside rlibs/dylibs instead of the full metadata, to keep their size smaller. It should be used in combination with `--emit=metadata`, so that the users of such a compiled library can still read the metadata from the corresponding `.rmeta` file. [This comment](rust-lang/rust#120855 (comment)) shows an example of binary/artifact size wins that can be achieved using this approach.

Contrary to rust-lang/rust#120855, this PR only introduces the new flag, along with a couple of run-make tests and documentation, but does not yet use it in bootstrap to actually compile rustc. I plan to do that as a follow-up step (along with integration in Cargo, which should ideally just always pass this flag to reduce the size of target directories).

Fixes rust-lang/rust#23366
Closes rust-lang/rust#29511
Fixes rust-lang/rust#57076

Another attempt of rust-lang/rust#93945 and rust-lang/rust#120855.

r? `@petrochenkov`
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
9 participants