-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
Is is actually pretty easy to strip them. The incantation is something similar to |
Ah, that's nice to know! |
Triage: no change, marking with enhancement, since it can be stripped. |
Don't cdylibs solve this? |
|
Note that it's not actually easy to strip these notes according to #26764. Another fun aspect is that systems which use That MiniDebuginfo procedure can probably add an exclusion, the same as it does for |
Triage: not aware of any work on this issue. |
Now that we have |
#93945 once I revive it would fix this issue. |
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
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.
The text was updated successfully, but these errors were encountered: