Build-time dependency on libstd causes binary to be dynamically linked.

[canndrew]

I'm not sure that this is actually a bug, but I found it surprising and I can't imagine why it would be necessary...

If I create a program that does nothing, it won't be dynamically linked against libstd:

$ cargo new --bin blah
$ cd blah
$ cargo build
$ ldd target/debug/blah
	linux-vdso.so.1 (0x00007ffd50de5000)
	libdl.so.2 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libdl.so.2 (0x00007f57b3eb5000)
	librt.so.1 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/librt.so.1 (0x00007f57b3cad000)
	libpthread.so.0 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libpthread.so.0 (0x00007f57b3a8f000)
	libgcc_s.so.1 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libgcc_s.so.1 (0x00007f57b3879000)
	libc.so.6 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libc.so.6 (0x00007f57b34c6000)
	/nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/ld-linux-x86-64.so.2 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib64/ld-linux-x86-64.so.2 (0x00007f57b432b000)

This is expected. Rust binaries are statically linked by default, even if we fill the program with a bunch of code.

However if I then add a dependency on the net-literals crate (and do nothing else) my program becomes dynamically linked:

// main.rs
#[macro_use]
extern crate net_literals;

fn main() {
    println!("Hello, world!");
}

$ cargo build
$ ldd target/debug/blah
	linux-vdso.so.1 (0x00007ffef091f000)
	libstd-152059dc9ab225d8.so => /home/shum/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-152059dc9ab225d8.so (0x00007f47cc4f8000)
	libc.so.6 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libc.so.6 (0x00007f47cc145000)
	libdl.so.2 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libdl.so.2 (0x00007f47cbf41000)
	librt.so.1 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/librt.so.1 (0x00007f47cbd39000)
	libpthread.so.0 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libpthread.so.0 (0x00007f47cbb1b000)
	libgcc_s.so.1 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/libgcc_s.so.1 (0x00007f47cb905000)
	/nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib/ld-linux-x86-64.so.2 => /nix/store/glb7dzs11di2cl66rsi8f49wraaj0pqd-glibc-2.26-75/lib64/ld-linux-x86-64.so.2 (0x00007f47cca50000)

It's this line that bothers me: libstd-152059dc9ab225d8.so => .... I don't know why this binary would need to be dynamically linked, my only guess is that it has something to do with net-literals using libstd at build time (net-literals is a proc-macro crate using the custom derive / proc-macro hack). Even so, I can't imagine why this would effect the resulting binary's runtime dependencies.

Ideas? I want to be able to statically link a binary like this.

[petrochenkov]

I cannot reproduce this with rustc 1.43.1 on Ubuntu Focal.

ldd output without net-literals:

        linux-vdso.so.1 (0x00007ffd97adf000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe53b23a000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe53b217000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe53b1fc000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe53b00a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe53b291000)

ldd output with net-literals:

        linux-vdso.so.1 (0x00007fffe10ce000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f94faa81000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f94faa5e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f94faa43000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94fa851000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f94faad8000)

In both cases libstd is linked statically as a rlib.