cdylib size regression on MinGW

[alexcrichton]

First reported here it looks like there was a regression in the range of e266888...c11f689 (nightly-2017-08-28-gnu and nightly-2017-08-30-gnu) to the size of a cdylib artifact in the project https://github.com/rkarp/rust-dll-demo/tree/879459c8612bfa178b660f480a56a738ca531bb1.

Locally I've reproduced this with:

$ cargo +nightly-2017-08-28-gnu build --release && ls -alh target/release/rust_dll_init.dll
-rwxr-xr-x 2 alex alex 268K Nov  6 09:26 target/release/rust_dll_init.dll
$ cargo +nightly-2017-08-30-gnu build --release && ls -alh target/release/rust_dll_init.dll
-rwxr-xr-x 2 alex alex 822K Nov  6 09:28 target/release/rust_dll_init.dll

[alexcrichton]

Also as reported if you run strip.exe over the resulting DLL they both shrink, but they both shrink to the same amount. The first nightly goes to 169K and the second goes to 173K.

[alexcrichton]

Running just strip.exe -g (only stripping debug info) doesn't shrink it as much but shrinks them to the same size, looks like more debuginfo is coming out the back.

[alexcrichton]

This may be related to #44107 where we're just shipping more debug info. @rkarp is this a problem for you? If so would you mind continuing the investigation?

[rkarp]

Oh it's not a problem for me at all. But I think at some point in the future it might be a good thing for rustup / cargo to provide a way to get rid of all the bloat, for example by stripping the resulting executable when building with debug = false or maybe even by using a pre-built std without debug info.

[alexcrichton]

Ok makes sense! In light of that I'm going to close this issue specifically for now.