rustc should not assume 'cc' is a multiarch linker

[amatus]

I configured and built rust with the extra target: arm-unknown-linux-gnueabihf. The build process used the correct compiler/linker (arm-linux-gnueabihf-g++) but when trying to build a rust program (with --target arm-unknown-linux-gnueabihf) rustc tries to link by passing -marm to cc and fails because cc is the host compiler and does not know how to link arm objects. Since the configure script has already figured out the correct compiler/linker, it would be nice if the built rustc could also use them.

[amatus]

Looks like platform.mk defines some variables in aid of selecting the correct linker.

RUSTC_FLAGS_arm-unknown-linux-gnueabihf := --linker=$(CC_arm-unknown-linux-gnueabihf)

[flaper87]

Visiting for triage.

platform.mk now defines this: RUSTC_FLAGS_arm-unknown-linux-gnueabihf := -C target-feature=+v7,+vfp3

@amatus could you try to reproduce this? I believe this was fixed already but I don't have a way to test it off-hand.

[luqmana]

@flaper87 if you look a bit further down, platform.mk has -C linker=$$(CXX_$(1)) -C ar=$$(AR_$(1))

That value though is only used during the build process. The final rustc binary doesn't know. One way to fix this would be to use those values from the Makefile and put them in a mapping from target=>linker and have it decide on the default linker based on that.

[flaper87]

@luqmana a-ha, thanks for pointing that out. I should've looked better and don't trust the git grep + git blame + git log combo. This still needs some work then!

[dcuddeback]

I ran into this today, too, although for arm-unknown-linux-gnueabi (without "hf" at the end).

$ rustc --target=arm-unknown-linux-gnueabi hello.rs
error: linking with `cc` failed: exit code: 1
note: cc '-marm' '-L' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib' '-o' 'hello' 'hello.o' '-Wl,--whole-archive' '-lmorestack' '-Wl,--no-whole-archive' '-nodefaultlibs' '-Wl,--gc-sections' '-Wl,--as-needed' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/libnative-1fb5e2c0-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/libstd-59beb4f7-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/librand-2ea8f361-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/libsync-305341d2-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/librustrt-d8560cb2-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/libcollections-d412c0c4-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/liballoc-1085c790-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/liblibc-4f9a876d-0.11.0-pre.rlib' '/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib/libcore-c5ed6fb4-0.11.0-pre.rlib' '-L' '/home/david/projects/hello/.rust' '-L' '/home/david/projects/hello' '-Wl,-Bdynamic' '-ldl' '-lpthread' '-lgcc_s' '-lpthread' '-lc' '-lm' '-Wl,-rpath,$ORIGIN/../../../../usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib' '-Wl,-rpath,/usr/local/lib/rustlib/arm-unknown-linux-gnueabi/lib' '-lcompiler-rt'
note: cc: error: unrecognized command line option ‘-marm’

I used to work around this by providing the --linker flag to rustc, but that doesn't seem to be supported anymore. I can still work around it by symlinking cc to the cross compiler.

[pnkfelix]

@dcuddeback you can still provide a linker at the command line to rustc; we just changed the interface.

Use rustc -C linker=path now.

You can see docs for this and many other codegen options via rustc -C help

[pnkfelix]

I think we should resolve this issue by changing the error message when linking via cc fails to explicitly suggest to the user that they try using the -C linker command line option to choose an appropriate linker. We should not attempt to build in further magic beyond that.

[dcuddeback]

@pnkfelix Thanks. That worked. I searched around for that last night, but overlooked the "additional help" section at the bottom of the output for --help.

[jerdfelt]

I ran into this recently as well. In particular, I was trying to use cargo to cross-compile.

While cargo has a --target option, which appears to be passed to rustc, it doesn't appear to have any way to pass -C options.

In my case, I'm cross-compiling to a different libc, but same architecture. As a result I didn't get any errors, but the resulting executables were linked incorrectly.

It would be great if the linker would be fixed for a given target triple (such as a config file or even compiled in to rustc). This would avoid pushing that data into all tools that use rustc (such as cargo).

[alexcrichton]

Cross compiles now have a linker specified almost all the time (with a prefix), so I don't believe that this is still an issue, so closing.

[Wilfred]

I'm still seeing this issue. I've downloaded the .rlib files for rustc from RustBuild to ~/.multirust/toolchains/stable/lib/rustlib as documented in ruststrap.

However, linking fails:

/tmp/foo $ cargo new --bin foobar

/tmp/foo $ cd foobar 

/tmp/foo/foobar $ cargo build
   Compiling foobar v0.1.0 (file:///tmp/foo/foobar)

/tmp/foo/foobar $ cargo build --target=arm-unknown-linux-gnueabihf
   Compiling foobar v0.1.0 (file:///tmp/foo/foobar)
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-L" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "/tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o" "-o" "/tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug" "-L" "/tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/deps" "-L" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib" "-L" "/tmp/foo/foobar/.rust/lib/arm-unknown-linux-gnueabihf" "-L" "/tmp/foo/foobar/lib/arm-unknown-linux-gnueabihf" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcollections-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_unicode-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librand-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liballoc-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liballoc_jemalloc-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liblibc-35c36e89.rlib" "/home/wilfred/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcore-35c36e89.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "rt" "-l" "pthread" "-l" "c" "-l" "m" "-l" "compiler-rt"
note: /usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/usr/bin/ld: /tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: Relocations in generic ELF (EM: 40)
/tmp/foo/foobar/target/arm-unknown-linux-gnueabihf/debug/foobar.0.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `foobar`.

To learn more, run the command again with --verbose.

Admittedly, ~/.cargo/build can be used to override this.

[ebeasant]

Just hit precisely this whilst cross compiling - rustbuild is trying to use the host linker/cc to link the final cross binaries rather than the correct cross architechture linker prefix
UPDATE using the rustbuild system, one needs to specify CROSS_COMPILE= in the environment before invoking - that then picks the correct compiler prefix for the cross compiler.