The author then goes and removes the lto-related code via objcopy. Which is fine, and great, and useful if you care about size more than having link-time optimization enabled for your end users.
But if you are just going to turn around and remove it, you probably shouldn't include it in the first place, which makes the original analysis of 132MB vs 15MB a little misleading.
You could also just ... not turn it on in the first place. You are doing a nonstandard build already.
The custom-use-case is the article's very raison-d'etre: "... I wanted to distribute a static library and the size was causing me problems. Specifically, I had a Rust library that I wanted to make available to Go developers."
The option is LTO.
The situation here is a bit like building a binary with debug info, and then saying, "But I don't need debug info and it is causing me size-problems, so I'll strip it." But the better option is to not build with debug info in the first place.
I missed that LTO was a non-default option! Thanks for pointing that out. In that case I agree.
kragen•2mo ago