|
|
|
|
|
by zRedShift
1303 days ago
|
|
You typically use build-std and possibly abort on panics or immediate-abort to disable the string formatting code in stdlib, and you do fat LTO. after stripping the binary, it’s pretty damn small.
If you want even further savings on std, you can use an utility that LZMA compresses the different ELF sections of your binary and unpacks them to memory at runtime. That’s language agnostic though… Regarding multiple rust binaries each bundling a copy of stdlib and inflating the space, this approach would only link the bits of the stdlib each binary uses, but still it’s not ideal. Three approaches I can think of are: 1. Use a file system that compresses its contents like btrfs or zfs or their embedded variant. It should reduce the redundancies. 2. Go the busybox way, as you said. This requires work but it’s definitely doable. 3. Link stdlib dynamically. There is a way, I believe. Rust maintains a “stable” ABI as long as you use the same rustc version if I’m not mistaken. 4. This is ridiculous, so I don’t even count this as a way, but what if you just stored the .a static libs and did the linking on demand into a temporary file that would then be executed? I personally have never encountered 50MiB optimized stripped and LT optimized rust binaries, only ‘materialized’ which was like 138MiB but it contained debug symbols, no LTO and is quite a large database application. |
|