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 · 8 comments

Comments

Projects
None yet
7 participants
@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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

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.

@steveklabnik

This comment has been minimized.

Copy link
Member

steveklabnik commented Jun 6, 2016

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

@jonas-schievink

This comment has been minimized.

Copy link
Member

jonas-schievink commented Jun 6, 2016

Don't cdylibs solve this?

@retep998

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

steveklabnik commented Sep 30, 2017

Triage: not aware of any work on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.