linking with cc failed when using lto = fat

[hellow554]

This bug can be reproduced only by using two crates, nothing else worked so far

A
├── B
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
├── Cargo.toml
└── src
    └── main.rs

A::Cargo.toml

[package]
name = "A"
version = "0.1.0"

[profile.dev]
lto = "fat"

[dependencies]
B = { path = "./B" }

A::main.rs is empty (or just a plain fn main() {}, doesn't matter).

B::Cargo.toml

[package]
name = "B"
version = "0.1.0"

[lib]
crate_type = ["rlib", "cdylib"]

B::src/lib.rs is empty as well (or any public function, doesn't matter as well)

When compiling this with cargo build, it errors:

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,-plugin-opt=O0" "-Wl,-plugin-opt=mcpu=x86-64" "-L" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/tmp.DW07BccpbK/A/target/debug/deps/B.42q3kclfyl99cg7w.rcgu.o" "-o" "/tmp/tmp.DW07BccpbK/A/target/debug/deps/libB.so" "-Wl,--version-script=/tmp/rustcS2Vx8P/list" "/tmp/tmp.DW07BccpbK/A/target/debug/deps/B.4c2aglkwgm7gduii.rcgu.o" "-Wl,--gc-sections" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/tmp/tmp.DW07BccpbK/A/target/debug/deps" "-L" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-0126adaa107032a6.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-57961a3692c39401.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-9fa9e50746f44a4c.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-251012178f8196c3.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-cafd612ee1b4bf88.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-140b53dc81f0d53c.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-cbaa12f3d93cc54c.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-a5bcc2d112e5a391.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-5ada18586d2652e2.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-ac41f78688451395.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-b1966f66603f91b6.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-428d15b56101bdc7.rlib" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-941f7f6bc622e313.rlib" "-Wl,--end-group" "/home/marcel/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-e915d31ab7edbbd4.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil" "-shared"
  = note: /tmp/tmp.DW07BccpbK/A/target/debug/deps/B.42q3kclfyl99cg7w.rcgu.o: file not recognized: file format not recognized
          collect2: error: ld returned 1 exit status

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (a74d1862d 2020-05-14)

[hellow554]

searched nightlies: from nightly-2020-01-01 to nightly-2020-05-14
regressed nightly: nightly-2020-05-03
searched commits: from 7f65393 to f05a524
regressed commit: dae90c1

cc #71716 @alexcrichton

[ehuss]

@alexcrichton It looks like when a dependency has mixed crate types (["cdylib", "rlib"]), cargo is passing -Clinker-plugin-lto, which causes the cdylib to be built incorrectly. Should Cargo avoid passing the flag in that scenerio, or should rustc be smart enough to ignore it when generating the cdylib?

Also, note, that this hits #60059 on macos where linking won't even start.

[alexcrichton]

Nah yeah this is a bug in Cargo's passing of -Clinker-plugin-lto, I'll look to fix this.

[alexcrichton]

This should be fixed in rust-lang/cargo#8254.

It's worth noting that with an rlib/cdylib crate type output LTO is turned off (due to #51009), so the LTO setting doesn't actually do anything other than cause more work during compilation otherwise.

[spastorino]

@alexcrichton we should close this one now, right?.

[alexcrichton]

Indeed!