Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upMove metadata out of dylibs #23366
Comments
This comment has been minimized.
This comment has been minimized.
|
Is is actually pretty easy to strip them. The incantation is something similar to |
This comment has been minimized.
This comment has been minimized.
Ah, that's nice to know! |
sanxiyn
added
the
A-metadata
label
Mar 16, 2015
retep998
referenced this issue
Apr 24, 2015
Closed
Create import library to go with dylib on Windows #24763
vadimcn
referenced this issue
Nov 29, 2015
Open
Metadata for DLLs should actually go in the LIB import library on Windows #29511
steveklabnik
added
the
C-enhancement
label
Jun 6, 2016
This comment has been minimized.
This comment has been minimized.
|
Triage: no change, marking with enhancement, since it can be stripped. |
This comment has been minimized.
This comment has been minimized.
|
Don't cdylibs solve this? |
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
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 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Triage: not aware of any work on this issue. |
vadimcn commentedMar 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.