Open vadimcn opened 9 years ago
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.
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.
Triage: no change, marking with enhancement, since it can be stripped.
Don't cdylibs solve this?
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.
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...
Now that #35409's 1bb14445160329c2ca5ff9c202e791ca0098d944 converted it away from an allocated note, it should be fine to be stripped.
Triage: not aware of any work on this issue.
Now that we have cargo strip
can we close this?
https://github.com/rust-lang/rust/pull/93945 once I revive it would fix this issue.
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.