Skip to content

Metadata for DLLs should actually go in the LIB import library on Windows #29511

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
retep998 opened this issue Nov 1, 2015 · 4 comments · Fixed by #137535
Closed

Metadata for DLLs should actually go in the LIB import library on Windows #29511

retep998 opened this issue Nov 1, 2015 · 4 comments · Fixed by #137535
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows

Comments

@retep998
Copy link
Member

retep998 commented Nov 1, 2015

Since metadata is only needed when building things, but the DLL is needed at runtime, it would be better if the metadata was moved to the LIB import library instead since that is only needed when building things as well. This would save significantly on space when distributing a binary with DLLs.

@apasel422 apasel422 added the O-windows Operating system: Windows label Nov 2, 2015
@vadimcn
Copy link
Contributor

vadimcn commented Nov 29, 2015

Arguably, the same could be said about dylibs on all platforms.
#23366

@vadimcn
Copy link
Contributor

vadimcn commented Nov 22, 2016

Can we close this now that we've got cdylibs?

@retep998
Copy link
Member Author

The problem still exists for regular dylibs though. It's just not as important of a problem anymore.

@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 24, 2017
@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

cc #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
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows
Projects
None yet
5 participants