MUSL target doesn't link on nightly #34978
Comments
alexcrichton
added
regression-from-stable-to-nightly
|
This is perhaps related to rust-lang-deprecated/rust-buildbot@417ddbf, specifically the update to the |
|
Er no, the |
|
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! |
|
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. |
|
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? |
|
I mean the assembler ("as") is generating it. It looks like there's a flag |
|
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! |
|
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. :( |
|
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? |
|
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. |
|
Err, actually, hang on; why are we building code targeting musl with -fPIC in the first place? |
|
I thought |
|
You could build with -fPIE instead. But nevermind, it looks like that doesn't actually help here. |
|
The tools team got a chance to talk about this during triage yesterday, and our conclusion was that this wasn't a super serious regression but we'd love to fix this! We're not entirely sure how to do so ourselves, so help would greatly be appreciated! |
alexcrichton
added
the
E-help-wanted
|
Is there a workaround for this other than sticking to an older nightly? |
|
@jwilm for me at least updating to a Ubuntu 16.04 docker container also fixed it, and I think the underlying issue according to @eefriedman is that a newer binutils is required to link. If either of those can be arranged I think that'll get things working again. |
|
Chiming in here, nightly broke my build as well, but only on what looks like are ubuntu machines, with the relocation (0x2a) as stated above: So I haven't tested with clang; unfortunately my build will be broken until the travis vm is updated (and hence gets a new linker that understands the reloc), I guess? |
|
@m4b the fix I know of currently at least is to update to Ubuntu 16.04 (perhaps in a docker image). Other than that though I know of a fix :(. If the fix is known though we'd be more than happy to apply it! |
|
I have also been bitten. 😄 There appear to be some similar reports out there from Rust packaged on Debian:
In both cases, it appears that the solution was updating binutils. It would be interesting to know why this affects only musl, as the above reports appeared to be normal Linux Rust versions. |
|
This may also negatively affect people who use Travis CI to test nightly builds or to produce easy-to-run redistributable binaries. Since they currently only support up to 14.04, I believe that you'd have to use their Docker building and abandon the faster container-based infrastructure. |
|
@shepmaster those two debian bugs look unrelated as I think they're related to how debian compiles the binaries. Although if we can figure out how to ask something to not emit these kinds of relocations I'd imagine it'd fix them as well! That is, the bug here I'm worried about is specifically related to the musl target, there should be no regression in the glibc target we're shipping because that container hasn't changed in ages. |
They definitely aren't this problem, but similar issues around mismatched binutils. I'd suppose you are right because Debian probably compiles their own version of Rust against their own binutils.
Oh, I agree. I was pointing out that I could see a project that wanted to make easily redistributable Linux binaries using Travis CI and building against musl running into this problem. |
|
I think we can fix this. So, using binutils version 2.26, I recompiled musl with similarly for the rest of the symbols. So this flag is documented in I assume the containers have a newer version since the assembler is producing the relocation, but it does look like the flag was added after the fact. On my system at least, with the above assembler version, it works as expected. Consequently, I think we can turn off this optimization for now, until whatever the appropriate time to turn it back on is. ( we will want to turn it back on as it turns GOT lookups into either immediates or RIP relative offsets, which will likely be faster) |
|
oh yea, you'll need to add this flag to the libunwind compilation step too I think, since i'm seeing similar optimizations (and unknown relocation failures) there :/ EDIT: if However, I'm also seeing the relocation in And just so it's here, I'm seeing the bad relocation in the following:
which I checked using something like this in the musl nightly dir: |
|
So if i'm understanding correctly, my which means my rustc's source had the build changes I added here #35178 However, when I inspect the musl build artifacts I'm still seeing the *RELX relocations in I take this to mean the changes in PR 35178 had no affect? Or am I misunderstanding something? |
|
This seems to be resolved now with last PR. I suggest we close unless others are still experiencing? |
|
This indeed works for me as well, thanks @m4b! |
I've been experiencing rust-lang#34978 with these two targets. This applies the hack in rust-lang#35178 to these targets as well.
add -mrelax-relocations=no to i686-musl and i586-gnu I've been experiencing rust-lang#34978 with these two targets. This applies the hack in rust-lang#35178 to these targets as well. r? @alexcrichton
add -mrelax-relocations=no to i686-musl and i586-gnu I've been experiencing rust-lang#34978 with these two targets. This applies the hack in rust-lang#35178 to these targets as well. r? @alexcrichton
See rust-lang/rust#34978 Allowing broken musl cross compilers through to stable really does break some Rust-based projects.
The mitigations for rust-lang#34978 involve passing `-Wa,-mrelax-relocations=no` to all C code we compile, and we just forgot to pass it when compiling musl itself. Closes rust-lang#39979
travis: Compile a more compatible libc.a for musl The mitigations for rust-lang#34978 involve passing `-Wa,-mrelax-relocations=no` to all C code we compile, and we just forgot to pass it when compiling musl itself. Closes rust-lang#39979
travis: Compile a more compatible libc.a for musl The mitigations for rust-lang#34978 involve passing `-Wa,-mrelax-relocations=no` to all C code we compile, and we just forgot to pass it when compiling musl itself. Closes rust-lang#39979
…lexcrichton Several changes to libunwind for SGX target Two fixes: * rust-lang#34978 bites again! * __rust_alloc are actually private symbols. Add new public versions. Also, these ones are `extern "C"`. Upstream changes (fortanix/llvm-project#2, fortanix/llvm-project#3): * b7357de Avoid too new relocation types being emitted * 0feefe5 Use new symbol names to call Rust allocator Fixes fortanix/rust-sgx#65
This was a recent regression:
The diff between the nightlies looks innocuous, so it looks like it was some change in deployment or images.
The text was updated successfully, but these errors were encountered: