"If you compiled your code with support for link-time optimization (LTO), it contains another copy (in the form of LLVM bitcode — more on that later) of all our code and the code of all our dependencies."
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.
Misleading how? If your first thought on looking at a Rust-generated static library is that it's fucking huge, it's not misleading at all for someone to tell you that Rust-generated static libraries are mostly LLVM bitcode that you can remove with `objcopy --remove-section .llvmbc`.
Your first paragraph appears to be a sarcastic paraphrase of the article; please correct me if I'm misunderstanding that. What's the somewhat custom use-case, and what's the option that jacks up the size? I don't see anything in the article that would obviously fit either description.
A very quick paraphrase, sure. Don't really think it is sarcastic, but whatever.
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.
"If you compiled your code with support for link-time optimization (LTO), it contains another copy (in the form of LLVM bitcode — more on that later) of all our code and the code of all our dependencies."
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.
Misleading how? If your first thought on looking at a Rust-generated static library is that it's fucking huge, it's not misleading at all for someone to tell you that Rust-generated static libraries are mostly LLVM bitcode that you can remove with `objcopy --remove-section .llvmbc`.
This somewhat custom use-case has an option turned on that jacks the size way up. Here is a hacky way to undo that option.
You could also just ... not turn it on in the first place. You are doing a nonstandard build already.
Your first paragraph appears to be a sarcastic paraphrase of the article; please correct me if I'm misunderstanding that. What's the somewhat custom use-case, and what's the option that jacks up the size? I don't see anything in the article that would obviously fit either description.
A very quick paraphrase, sure. Don't really think it is sarcastic, but whatever.
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 don't think of distributing a static library as a particularly custom use case, but more as the default way to distribute a compiled library.
I missed that LTO was a non-default option! Thanks for pointing that out. In that case I agree.
The option is LTO
Seems to be a dupe: https://news.ycombinator.com/item?id=46074222