cargo subcommands are much larger than necessary due to static linking

[huonw]

The following are the sizes of the target directory after a plain make where

• dy is crate_type = "dylib" in the cargo lib
• static is crate_type = "rlib"
• opt is compiling everything with -O
• no-opt is no -O at all
• lto is -Z lto for the binaries.

$ du *-target
6240    dy-no-opt
4236    dy-opt
29184   static-no-opt
23112   static-opt
20368   static-opt-lto

Of course, the space benefits of dynamic linking may out weighed by the ease of deployment (etc.) with static linking, but this difference will likely only get worse as there are more subcommands.

[alexcrichton]

The major benefit of static linking is that we can update rust without having to update cargo. One possibility for cutting down the size would be to distribute libcargo as a dylib, but I'm not sure how much of a win that would be.

[huonw]

@alexcrichton I... think I'm measuring distributing libcargo as a dylib (that is, the only change I've made for the dynamic linking is making the crate type of libcargo "dylib").

[alexcrichton]

Ah that's right. I was thinking we could link libcargo dynamically but the rest of the standard libraries statically, but I do not believe that's currently possible.

[alexcrichton]

I'm going to close this as this is currently an explicit design decision to be able to update rust independently of cargo itself. The vast majority of the size of each command comes from the standard library, which would otherwise be solved by dynamically linking it (tying it to one rust version).

We may be able to revisit this in the future once rust is more stable, but for now I'm going to close this as working as intended.