Rustup: Targeting linux on OSX yields compilation errors

[netgusto]

Compiling on OSX for linux yields some error.

error: linking with `cc` failed: exit code: 1
ld: unknown option: --as-needed

To reproduce :

$ rustup target add x86_64-unknown-linux-gnu
$ cd  /tmp
$ mkdir supworld
$ cd supworld
$ cargo init --bin
$ cargo build --target=x86_64-unknown-linux-gnu -v
   Compiling supworld v0.1.0 (file:///private/tmp/supworld)
     Running `rustc src/main.rs --crate-name supworld --crate-type bin -g --out-dir /private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug -L dependency=/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug/deps`
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug/supworld.0.o" "-o" "/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug/supworld" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug" "-L" "/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug/deps" "-L" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4fda350b.rlib" "/Users/user/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-4fda350b.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "compiler-rt"
note: clang: warning: argument unused during compilation: '-pie'
ld: unknown option: --as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)

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

Caused by:
  Process didn't exit successfully: `rustc src/main.rs --crate-name supworld --crate-type bin -g --out-dir /private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug -L dependency=/private/tmp/supworld/target/x86_64-unknown-linux-gnu/debug/deps` (exit code: 101)

Environment:

# OSX: El Capitan 10.11.3
$ cc -v
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

$ rustc --version
rustc 1.8.0 (db2939409 2016-04-11)

$ rustup --version
rustup 0.1.12 (c6e430a 2016-05-12)

[Diggsey]

See #462

[urschrei]

To expand on @Diggsey's comment, I tried to get the linker-and-compiler route working on OSX a couple of months ago using crosstool-NG, and it was show-stoppingly tedious, requiring specifically-formatted volumes and all sorts of download-and-rerun-the-configure loops. I gave up after about three hours, though it was admittedly a Friday-afternoon project.

[netgusto]

If anyone has a procedure to make it compile, please share it ! Otherwise, I guess this can be closed.

[hwsdien]

@netgusto did you solve this problem?

[messense]

Running into this problem.

[brson]

Cross-compiling to OS X is one of the thinks I'd like to solve with 'NDK support' - where rustup automatically installs the C toolchain components for you. NDK support is one of the next major features I'm supposed to add to rustup, but it's been on the backburner for quite a while.

[aleksanb]

I've given up on getting a functional cross compilation setup for macOS to x86_64-unknown-linux for the moment. To others who find this thread: follow the advice over at rust-cross and setup a docker machine with the build environment, and compile from there.

[tbillington]

In the same boat. Is there some dependency/specific linker we could install using brew/some other means to get this working ?

[jml]

By creating a .cargo/config file in my repo and adding the following:

[target.x86_64-unknown-linux-musl]
linker = "CORRECT_LINKER_HERE"

I'm able to _specify_ a different linker, but I have yet to figure out _which_ linker to actually use. I've tried gcc, llvm-gcc, and clang.

kali on #rust suggested "a small shell script to wrap gcc" but as of now I don't have the details of what such a script would look like. Diggsey suggested gold, but I cannot figure out how to install that on OS X.

This is my system ld:

$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-274.2
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.0.0, (clang-800.0.42.1)
TAPI support using: Apple TAPI version 1.30

Debugging this is made more difficult as many websites assume that I want the GNU ld for linking Mach-O binaries, rather than ELF binaries.

[kinnison]

I'm going to assume this is no longer an issue for the OP, and if so that discussion on the users forum may be better since rustup is not really involved with setting up cargo for cross compilation.

[netgusto]

I can confirm it is still an issue, just not for me. I can reproduce it on Catalina.

That discussion on the users forum may be better since rustup is not really involved with setting up cargo for cross compilation.

Fair point! Thanks.