Linking liblibc using musl target fails ("unrecognized relocation") with the new nightlies

[golddranks]

Here's a dockerized test case: https://github.com/golddranks/libc_regression_test/ (run with docker build .)

Here's the error:

  = note: /usr/bin/ld: /root/.rustup/toolchains/nightly-2017-02-19-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-95af4192ed69a1c8.rlib(exit.lo): unrecognized relocation (0x2a) in section `.text.libc_exit_fini'
          /usr/bin/ld: final link failed: Bad value
          collect2: error: ld returned 1 exit status

The linking error seems to happen only with the musl target. I originally posted this as rust-lang/libc#529, but because the breaking is dependent on the nightly, it seems that this is an rustc issue rather than an issue of the libc crate.

After testing with various nightlies, it seems that the nightly nightly-2017-02-16 installed - rustc 1.17.0-nightly (62eb6056d 2017-02-15) is the first one that breaks. The nightly before that, nightly-2017-02-13 installed - rustc 1.17.0-nightly (956e2bcba 2017-02-12) is the last one that works.

So that seems to imply that the commit that introduced this regression is in the range 956e2bcba..62eb6056d. Any thoughts about which one it might be?

[TimNN]

I can reproduce this with the docker image (by the way @golddranks, there's no need to build musl yourself).

Diff for 956e2bcba..62eb6056d.

This works fine on stable, thus tagging as a regression.

[TimNN]

I cannot reproduce this with a current ubuntu release. After some looking around, I believe that the problem could be that the binutils version used by the buildbots / travis is to new.

During the time this was introduced, the nightlies were switched from buildbot to travis so I guess this may have caused this problem (cc @alexcrichton).

[golddranks]

@TimNN, thanks for the pointer, the Dockerfile uses now the distro-provided musl. (But errors nevertheless, so it isn't just the self-built musl that has this problem.)

[TimNN]

@golddranks: I actually meant to say, that you don't need to get any kind of musl yourself: musl is linked statically into the rust stdlib (unless I am misremembering something).

[golddranks]

Ah, really? I've been building musl stuff with native dependencies, which I have had to build by hand, so I've always needed the musl build environment anyway, so I didn't know this :D

[alexcrichton]

This looks like #34978 and agreed this is likely a regression in switching nightlies to Travis/AppVeyor. The fix last time was to pass -Wa,-mrelax-relocations=no when compiling C code, but we should be doing that. This may just erroneously not be ferrying along those arguments?

Another possible bug, although I forget if it has this exact signature, is that when we compile binaries with a very new binutils it ends up being incompatible with older binutils (for whatever reason). There's typically flags we can pass, though, to disable the "new binutils behavior incompatible with older binutils".

Also FWIW this is how we build nightlies

Oh.... maybe it's because we don't pass the flag when building musl itself.

[alexcrichton]

Ok, I've got a fix at #40019

[golddranks]

The fix landed on the commit 1572bf1, but the same error occurs even on the latest nightly (60a0edc6c 2017-02-26), which is based on a commit that landed after 1572bf1.

So the problem isn't solved yet.

[golddranks]

Ah, but this times the error is:

  = note: /usr/bin/ld: /root/.rustup/toolchains/nightly-2017-02-27-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc_jemalloc-4b74d6f2808677d3.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

So it seems that jemalloc needs the same treatment?

[alexcrichton]

@golddranks oh I think that's #40130 (an accidental typo)

[BurntSushi]

Whatever it was, this is fixed for me now in the 2017-03-02 nightly: https://travis-ci.org/BurntSushi/ripgrep/jobs/206572974

[BurntSushi]

Thanks @alexcrichton! :-)