這篇主要是參考 [Advanced Linking: Static linking] 這節。
因為平時在工作時如果有處理到 Go 程式，沒有意外的話，編譯過程會產出一個 static linked binary，這對 deploy 流程很方便，所以我想在 Rust 底下也比照辦理。
截自目前，在 Linux 底下，Rust 如果要這樣做，libc 標準函式庫要用 musl，而不是最常見的 glibc，所以要先安裝 musl，在 Arch Linux 底下就是執行：
sudo pacman -S musl
多裝 musl 不會有與 glibc 打架的情況，所以可以大膽放心裝下去。（又或者是我還沒踩到兩者打架的雷？）
然後利用 rustup 工具，新增一組支援 x86_64-unknown-linux-musl 這個 build target 的 Rust toolchain：
rustup target add x86_64-unknown-linux-musl
這樣基本環境其實就搞定了，當然，在建置時，除非是將 x86_64-unknown-linux-musl 設為預設 toolchain，不然都需要特別指定使用這個 target：
cargo build --target=x86_64-unknown-linux-musl可以用 ldd 與 file 指令觀察、對照一下這組 target 的 binary 與預設的 target 有什麼不同。
實務上，我發現如果把這個 build 出來的 binary 丟進 Docker 裡，用 alpine:3.6 這個 base image 來做個無腦執行容器映像，則會發生 ld.so, ld-linux.so 路徑、檔名不符的問題，換用 debian:stable-slim 就沒這阿雜事了。
考慮到目前頻寬足夠充裕的現實，一個約 4MB 的 alpine:3.6 與一個約 55MB 的 debian:stable-slim，疊上一個約 20MB 的 static linked binary，在 push 效率上，其實對人來說，是感覺不到會覺得「煩」、「痛」這樣的差異的，我自己真的不太喜歡使用 Alpine 這種為了精簡而常常埋雷的 base image 來給自己找麻煩，不過這與本篇沒有直接相關，只是我的一點小抱怨罷了。
