rustc --verbose does not print linker invocation

[whitequark]

To reproduce:

// main.rs
fn main() {}

$ rustc --version
rustc 1.13.0-nightly (eac41469d 2016-08-30)
$ rustc --verbose main.rs
$

This might be an OS X-specific bug, I have not tried 1.13 on any other OS.

[steveklabnik]

This might be an OS X-specific bug, I have not tried 1.13 on any other OS.

It does not on Linux either.

[alexcrichton]

AFAIK this has never been the behavior, so I'm not sure this is a bug but rather a feature request?

[whitequark]

@alexcrichton Hm, I kind of assumed that it should be already the case, since cargo as well as basically every other compiler toolchain in existence respects this convention. But I guess this is a feature request, yes.

[japaric]

FWIW, you can use rustc -Z print-link-args foo.rs to see the linker invocation.

[ctaggart]

I haven't been able to figure out how to get the ld linker to be verbose when using Cargo. Any ideas?
https://stackoverflow.com/q/44354906/23059
ctaggart/octh#18 (comment)

[japaric]

@ctaggart use cargo rustc instead of cargo build. Example

$ cargo new --bin hello

$ cd hello

$ cargo rustc -- -Z print-link-args
   Compiling hello v0.1.0 (file:///home/japaric/tmp/hello)
"cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/japaric/tmp/hello/target/debug/deps/hello-ff76c8194d22830b.0.o" "-o" "/home/japaric/tmp/hello/target/debug/deps/hello-ff76c8194d22830b" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/japaric/tmp/hello/target/debug/deps" "-L" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-35ad9950c7e5074b.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-20a50a22d4c2b1e9.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-b479831207997444.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-f4f0ae88f5ad8ad4.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-fb44afc024bbc636.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-14b8f3202acdad6a.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-10b591f1a68dd370.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-28913dc5a1e63cd7.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6ecacccb5bdc4911.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-bfaa82017ca17cb2.rlib" "/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-863b57a66ba6c3e1.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"
    Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs

[Mark-Simulacrum]

I'm going to close this in favor of #38206 which suggests we print both invocations and output.

[wez]

Note that the -Z print-link-args suggestion doesn't work if the crate-type is staticlib

[japaric]

@wez rustc doesn't invoke the linker when producing a staticlib, at least not on Linux. (libfoo.a is just an archive of object files; rustc uses the built-in LLVM ar to build the archive)

[wez]

Right... my point is that it is impossible to see what is being run. It’s super frustrating on macOS where dtrace is hobbled; there’s no easy way to snoop this sort of thing at a system level