Shrinking While Linking
28 points by ingve 6 days ago | 8 comments
  • kragen 3 days ago |
  • compiler-guy 3 days ago |
    "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.

    • kragen 3 days ago |
      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`.
      • compiler-guy 3 days ago |
        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.

        • kragen 3 days ago |
          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.
          • yellow_lead 3 days ago |
            The option is LTO
          • compiler-guy 3 days ago |
            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.

            • kragen 3 days ago |
              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.