MUSL target doesn't link on nightly

[alexcrichton]

This was a recent regression:

$ cargo new foo --bin
$ cd foo
$ rustup run nightly-2016-07-19 cargo build --target x86_64-unknown-linux-musl
   Compiling foo v0.1.0 (file:///home/alex/code/foo)
$ rustup run nightly-2016-07-20 cargo build --target x86_64-unknown-linux-musl
   Compiling foo v0.1.0 (file:///home/alex/code/foo)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-nostdlib" "-static" "-Wl,--eh-frame-hdr" "-Wl,-(" "-m64" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/crt1.o" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o" "-L" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib" "/home/alex/code/foo/target/x86_64-unknown-linux-musl/debug/foo.0.o" "-o" "/home/alex/code/foo/target/x86_64-unknown-linux-musl/debug/foo" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/alex/code/foo/target/x86_64-unknown-linux-musl/debug" "-L" "/home/alex/code/foo/target/x86_64-unknown-linux-musl/debug/deps" "-L" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/librand-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libcollections-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_unicode-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc_jemalloc-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c8005792.rlib" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-c8005792.rlib" "-l" "compiler-rt" "/home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o" "-Wl,-)"
  = note: /usr/bin/ld: /home/alex/.multirust/toolchains/nightly-2016-07-20-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc_jemalloc-c8005792.rlib(jemalloc.pic.o): unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: Could not compile `foo`.

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

The diff between the nightlies looks innocuous, so it looks like it was some change in deployment or images.

[alexcrichton]

This is perhaps related to rust-lang-deprecated/rust-buildbot@417ddbf, specifically the update to the linux-cross build.

[alexcrichton]

Er no, the linux container, not the linux-cross container

[alexcrichton]

Ok, looks like this is due to the update to Ubuntu 16.04. I've got a suite of docker containers which are built each night which is how I discovered this regression. I'm personally running Ubuntu 14.04 on my computer (in the description), and the relevant Dockerfile is using Ubuntu 15.10 which also regressed. If I change that to Ubuntu 16.04, however, it works.

So... I wonder what changed!

[eefriedman]

0x2a is R_X86_64_REX_GOTPCRELX; newer versions of binutils generate it, but it isn't supported by older versions of binutils.

I'm guessing the cause is that you upgraded binutils on your nightly builder.

[alexcrichton]

Interesting! Could you clarify what you mean by newer versions of binutils generating it? The error here I believe is just using an object generated by what is presumably a newer gcc, not necessarily something linked with a newer linker. In that sense is there a flag we can pass to gcc to disable this behavior?

[eefriedman]

I mean the assembler ("as") is generating it.

It looks like there's a flag -mrelax-relocations=no to turn it off... you might be able to pass -Xassembler -mrelax-relocations=no or something like that to gcc. Or you could build with clang, where the integrated assembler doesn't do this by default.

[alexcrichton]

Hm I unfortunately can't seem to find any documentation pertaining to that flag, do you have any links on hand with the information here? Also, thanks for the investigation!

[eefriedman]

https://www.sourceware.org/ml/binutils-cvs/2016-02/msg00038.html . Taking another look, I'm not sure it's actually part of any released binutils version. :(

[alexcrichton]

Weird, surely I'm not using that old of a distribution, Ubuntu 15.10 is less than a year old? There's got to be some way we can change how we compile these objects, because the standard glibc target works ok, just musl is broken?

[eefriedman]

Compiling them with clang should work, I think.

It looks like you'll only end up with the relocation in question if code computes the address of a global using a GOT lookup, so it's possible the glibc target is just getting lucky.

[eefriedman]

Err, actually, hang on; why are we building code targeting musl with -fPIC in the first place?

[alexcrichton]

I thought -fPIC was required to build position-independent executables at the end?

[eefriedman]

You could build with -fPIE instead. But nevermind, it looks like that doesn't actually help here.