Wrong linker order on Linux produces error.

[ralfbiedert]

Background

Same background as #62588.

We have a Rust project (lets call it dylib) where we want to produce a shared library (.dll, .dylib, .so) for various platforms. As part of the build process we also want to verify the provided headers match the library.

To do that we have a separate project dylib_test, where we extract C doc tests into individual generated_nnn.c files, produce a generated.rs file that knows all C tests, and emits a #[test] for each, which we then want to run with cargo test.

The dylib project should only emit a cdylib, and the dylib_test should only link against that cdylib, to make sure the actual .dll, ... works.

Problem
When linking against dylib, the #[link(name = "dylib")] on Linux, Rust seems to place the linker arguments in the wrong order. If I execute cargo test --release on a regular Ubuntu 18.04, I get the following error message:

   Compiling dylib_test v0.1.0 (/home/rb/source/rust_issues/dylib_test)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50.dylib_test.zejn0h82-cgu.0.rcgu.o" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50.dylib_test.zejn0h82-cgu.1.rcgu.o" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50.dylib_test.zejn0h82-cgu.2.rcgu.o" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50.dylib_test.zejn0h82-cgu.3.rcgu.o" "-o" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps/dylib_test-38f2a187e2076f50.17cl81ouu8r6hb2h.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/deps" "-L" "/home/rb/source/rust_issues/target/release/deps" "-L" "/home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/build/dylib_test-79d0299f44818f6a/out" "-L" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-ldylib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-ltest_harness" "-Wl,--no-whole-archive" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-e0801b53662ffc3d.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-cdfff332358115a2.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-62071f29a3dbf8f6.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-4b58e49d8af86ebc.rlib" "-Wl,--start-group" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-01f0f08cf2f2f6b6.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-9f0c2fa34243df71.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-81b8dc5cee87c54f.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-5ce6b7614ea27cf6.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-d24f36a9b5d22481.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-012c35d529026afb.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-399b288ebcb05138.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-6f4dc2e9bc06e747.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-ed847dc2c2fa0fa7.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-391fc13a5e3777b7.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-7ad47fc2d32a5f8d.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-fc50d0a6a1e38bf8.rlib" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-8bfbea44a5cccf7b.rlib" "-Wl,--end-group" "/home/rb/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-af944f07dc08b653.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /home/rb/source/rust_issues/target/x86_64-unknown-linux-gnu/release/build/dylib_test-79d0299f44818f6a/out/libtest_harness.a(would_be_generated.o): In function `test_harness':
          would_be_generated.c:(.text.test_harness+0x3): undefined reference to `get_version'
          collect2: error: ld returned 1 exit status

Interestingly -ldylib (which contains get_version) is already in that command. When I run the same cc with an extra -ldylib added to the end works. This is related to this Stackoverflow comment, that apparently

Libraries must be listed after the objects that use them (more precisely, a library will be used only if it contains a symbol that satisfies an undefined reference known at the time it is encountered).

Steps

1. Clone https://github.com/ralfbiedert/rust_issues/tree/dylib_issues
2. Run cargo test (from Linux)

Possible Solution(s)
?

Notes

Output of cargo version:

cargo 1.37.0-nightly (4c1fa54d1 2019-06-24)
rustc 1.38.0-nightly (6e310f2ab 2019-07-07)
x86_64-unknown-linux-gnu

[alexcrichton]

Thanks for the report! I've transferred this issue to rust-lang/rust since rustc is the one generating the linker command, not Cargo

[Enselic]

Triage: the repro repo has disappeared, and without a way to reproduce it is not feasible to make progress. Closing as obsolete.