Binaries built with 1.21.0 are 5x the size of those from 1.20.0

[saarw]

We are building a library on Mac/Linux/Windows that ends up being ~2 MB when built with Rust 1.20 and Rust 1.19, but when I am building it with Rust 1.21.0 or nightly, the library becomes ~10 MB.

In both cases I'm building with "cargo build --release"

[saarw]

Nevermind nightly, hadn't updated rustup in a while. The binaries are back down in size with the most recent nightly, but not the current beta (1.22.0-beta.3 (cc6ed06 2017-11-13)). Please backport this fix so it makes 1.22.0!

[kennytm]

@saarw Have you tried running strip on the resulting library and see if the sizes between versions become similar?

[saarw]

Running strip -x -u -r reduces the binary size on mac from 9.3M to 7.6M so there is still a long way to go. Running without arguments doesn't work (error message "symbols referenced by indirect symbol table entries that can't be stripped"). Isn't there also a chance that too aggressive stripping will break the code's ability to unwind panics?

[kennytm]

@saarw The worst it can do is make all symbols <unnamed>. The debug symbols (*.dSYM) are stored outside of the binary, so strip won't affect the backtrace in debug build.

Since 1.22 will be released in 2 days, there's likely no chance to backport fixes for this which isn't a really serious bug. 1.23 will also enter beta soon, so the bug will naturally go away in 6 weeks.

Would you mind to share the library for comparison though? We may still like to know what caused the size fluctuation.

[saarw]

I can't share the library, but you can replicate the difference by cloning the hyper crate and adding the following to Cargo.toml

[lib]
crate-type=["rlib", "cdylib"]

When you build it with 1.20.0, you get a dylib of about 160K, while the same lib is 3+ M when built with 1.21.0

[kennytm]

Test sizes on x86_64-apple-darwin:

Version	cdylib size	rlib size
1.17.0 (56124baa9 2017-04-24)	143596	3166392
1.20.0 (f3d6973f4 2017-08-27)	165132	4143528
1.21.0 (3b72af97e 2017-10-09)	3313512	4135066
1.22.0-beta.3 (cc6ed0640 2017-11-13)	3068668	3940032
1.23.0-nightly (33374fa9d 2017-11-20)	11256	3906204

However, if you run nm hyper.dylib, we'll find,

• The cdylib of 1.20.0 only contains code from std and core
• The cdylib of 1.21.0 and 1.22.0 do contain actual code from hyper (and futures and mio and ...)
• The cdylib of 1.23.0 again only contains code from core.

Since hyper does not export anything as extern "C", it is probably correct that nothing about hyper is placed into the final cdylib. (@saarw maybe you should nm check if the cdylib produced by nightly is actually complete 😝)

I'm going to guess the fix was introduced in #45575.

[nagisa]

crate-type=["rlib", "cdylib"]

See #45613 for a workaround. Also marking this as a duplicate of the linked issue.

EDIT: the work around is to compile rlib and cdylib artifacts separately, not at the same time as specified by #45613 (comment)