ripgrep fails to build with MUSL on Linux since the nightly release on 2019-03-15 #59411
Comments
jonas-schievink
added
A-linkage
|
Exactly the same problem with exactly the same setup here: https://travis-ci.org/svenstaro/miniserve/jobs/510971585 |
|
Works fine with |
|
I get the same error message for |
|
It looks like it depends on the version of binutils: With 2.28-5 from debian/stretch I can build the binary successfully, with 2.25-5+deb8u1 from debian/jessie I get the mentioned error. |
|
I was afraid something like that can happen when tinkering around #58575 but I was able to compile I'll see if I can reproduce it. sidenote: Ubuntu 14.04 becomes EOL next month. |
|
I was able to reproduce it in Ubuntu 14.04 container and verified that #59468 fixes it. |
|
@mati865 Thank you!! |
|
Sorry for breaking it, when I was testing dozen of different distros I didn't even think of running it on distro with so old binutils. |
|
Yeah unfortunately Ubuntu 14.04 is the default Linux VM on Travis. :-( |
|
triage: P-high. driveby: approving PR #59468. |
|
triage: assigning self since I cannot assign @mati865 |
musl: build toolchain libs with -fPIC Fixes rust-lang#59411
Rust is having problems with trusty, in particular, see this bug I filed: rust-lang/rust#59411 This was purpotedly fixed in rust-lang/rust#59468, but it appears the issue is still occurring. This commit tries to update to Ubuntu 16.04 in the hope that it will fix this problem.
|
Did this make it into a recent nightly? It looks like the (I'm seeing about switching to xenial.) |
Rust is having problems with trusty, in particular, see this bug I filed: rust-lang/rust#59411 This was purpotedly fixed in rust-lang/rust#59468, but it appears the issue is still occurring. This commit tries to update to Ubuntu 16.04 in the hope that it will fix this problem.
|
Weird, I reproduced it locally and tested it before opening PR. I'll look into it today (CEST time). |
|
I can easily reproduce it installing toolchain with I'll try few ideas using builds from Rust and report here in a few days. |
|
The issue only manifests when building with Technical informations:
After some digging I found this line to cause the problem: Line 48 in 20dbf28 cc @alexcrichton can I ask you for some directions where I should look or how long those old platforms should be supported? |
|
@mati865 we don't really have a hard-and-fast policy, but rather "we keep things working as long as it's reasonable". If it's not reasonable to keep supporting something then we can explicitly evaluate at that time if it feels right to drop. |
|
I've tried pushing Disabling this makes libraries compatible with older buintuils: Lines 640 to 646 in 3750348 Noticed one more thing, before #58575 there was single |
|
I'm pretty lost here myself so I don't think I can really provide much guidance. I don't even know if this is still an open or closed issue, or if we're looking to go beyond what's already in-tree. Could a summary be redone of what's currently happening? |
|
It probably should be reopened. The short description is that musl builds are failing on Ubuntu Trusty, which is the default Linux environment on Travis. |
|
It still fails with errors from the first comment. First time I tried to fix it with #59468 it worked on my machine but nightly builds were still broken. Later I discovered it happens only on I've tried forcing Before #58575 (introduction of musl host toolchain) there was single After #58575 there are two
|
|
Ok so instead of |
|
er, Ok instead of golfing versions for various tools, it looks like a "hello world" fails in 14.04 and succeeds in 16.04 (ubuntu). The main difference here is binutils that we're interested in, and it jumped from 2.19 to 2.23 in those two revisions. I wasn't able to quickly test any other versions of binutils, but reading the changelog turns up: I suspect that's what's happening here where binutils in Ubuntu 14.04 didn't understand compressed debug sections but in Ubuntu 16.04 it does. Presumably at some point in our toolchain we're producing compressed debug sections either by accident or as part of some build script. My guess is that either the upgraded version of gcc turns it on by default or musl does or something like that. We probably need to figure out where |
|
It also looks like |
|
😕
Musl is ELF just like glibc, PE/COFF is for MinGW. |
|
Ah oops I was looking at glibc versions rather than binutils versions. That being said I think it's ironically the same culprit: |
|
As I said earlier I tried switching You can ping me on Discord BTW. |
|
@mati865 this isn't an aspect of binutils or such to build the toolchain, it has to do with the binaries we're producing using features that aren't supported by older toolchains. It doesn't matter what we build the musl toolchain with so much as how we build it. Using nightly-2019-03-15 compiling hello world works, using 2019-03-16 fails. Inspecting gets us: This seems highly likely to be related to compression of debuginfo at least, if not more aspects of the binaries. |
|
That looks clearer. I assumed it would use binutils from musl-toolchain because we point Rust to use GCC from it: I can try to point it to musl-toolchain binutils 2.25.1 or disable compression, whatever you like and open PR tomorrow (or reply here if it doesn't help). |
sfackler
added
the
regression-from-stable-to-beta
|
This has slipped to beta now I believe. |
|
so my downgrade to binutils 2.25.1 should have fixed this. Probably Rust's build systems at some point calls Anyway disabling debug sections compression fixed the issue: @alexcrichton thank you for help! |
musl: do not compress debug section This should be beta nominated. Fixes #59411 (this time for real). Test with `DEPLOY=1 ./src/ci/docker/run.sh dist-x86_64-musl`, without `DEPLOY=1` libs are built without debuginfo. r? @alexcrichton
The last successful build was with the Rust nightly released on 2019-03-14 (bc44841): https://travis-ci.org/BurntSushi/ripgrep/jobs/506631861
The first failing build was with the Rust nightly released on 2019-03-15 (52e8856): https://travis-ci.org/BurntSushi/ripgrep/jobs/507121811
There weren't any changes on my end. (Last commit to ripgrep master was 2019-03-03.)
Here's the pertinent error:
Unfortunately, I can't seem to reproduce this on my local system. One possible difference between my local system (Archlinux) and the Ubuntu CI on Travis is that Ubuntu might be using an older version of
musl-gccvia themusl-toolspackage. I havemusl 1.1.21locally. According to the logs in the link above, CI is usingmusl 0.9.15(for both the last successful build and the first failing build).The text was updated successfully, but these errors were encountered: