Undefined reference to getauxval in function init_have_lse_atomics when compiling to nightly aarch64-unknown-linux-musl
#89626
Comments
XAMPPRocky
added
O-Arm
rustbot
added
I-prioritize
XAMPPRocky
changed the title
getauxval' in function init_have_lse_atomics when compiling to nightly aarch64-unknown-linux-musl`getauxval in function init_have_lse_atomics when compiling to nightly aarch64-unknown-linux-musl
|
The reference is introduced in llvm/llvm-project@a4ac434#diff-a380831627112e2516d39595d94e711db7ac63316b9c411aa77af4a561d15ab8 |
|
@rustbot label E-needs-bisection |
rustbot
added
the
E-needs-bisection
|
forcing notification for prioritization @rustbot label -I-prioritize +T-compiler +I-prioritize |
rustbot
added
the
T-compiler
apiraino
added
I-prioritize
|
See also cross-rs/cross#598. (NB. that issue has a bit of waffley analysis, but also a workaround.) |
|
Any ideas for the equivalent workaround when not using cross? aarch64-unknown-linux-musl is the host as well as the target here (CI build in an Alpine container) and I'm hitting this issue. I tried setting either |
|
@jbg I know that this issue is all about |
|
Thanks! this particular codebase has to use a gated feature so going back to |
|
@jbg Ah, that's interesting. For me, it looked like there was no libc being linked at all, so adding it to the end worked out well. For you, I'm guessing there's some reference to libc earlier in the linker command line. Unfortunately if I remember rightly the linker command-line is order-sensitive, with later mentions of object/library files supplying symbols needed by earlier files. But I thought also that mentioning a library was idempotent! What are the duplicate symbols you see? Can you run your build with |
|
I just noticed that the
|
|
Probably related to #83655. |
|
Actually even helloworld fails to compile with |
Great catch! The timing looks just about right - it must have been about 12-13 days ago I noticed the problem that I subsequently reported in cross-rs/cross#598, and it looks like #83655 was merged into master about 14 days ago.
This matches what I saw with cross-rs/cross#598, where a |
|
Yes, very likely. I've hit similar issues with outline atomics with C/C++ code on aarch64-unknown-linux-musl, which are fixed with |
|
I tried to use this workaround: But it doesn't change anything. Is it because |
|
Hmm. What works for me as a workaround with helloworld is using lld for linking like this: |
|
FWIW, I'm still running into issues with getauxval missing on aarch64 when linking with C code. I'm not sure what the issue is exactly, though this issue seems to be the most likely related that I can find. I'm not sure how to minimize, but here's a dockerfile that reproduces it: FROM alpine:3.18.2
RUN apk add pkgconfig build-base curl openssl-dev openssl-libs-static
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rustup.sh
RUN sh ./rustup.sh --profile minimal --default-toolchain nightly -y
ENV PATH=/root/.cargo/bin:${PATH}
WORKDIR /tmp
RUN cargo new foo
WORKDIR /tmp/foo
RUN cargo add git2
RUN echo 'use git2::*; fn main() { git2::Repository::init("x").unwrap(); }' > src/main.rs
# This also fails with -F git2/vendored-openssl.
RUN cargo runThis fails with: Above are noted several workarounds: I'm not sure were the problem lies, though #76992 seems suspicious. |
|
Please can this issue be reopened. It still manifests on stable rust today, but only under limited circumstances. As others have noted, the issue is caused by Oddly, I have two different uses of I can see that the fix of using |
|
It's possible to trigger this by building the default "hello world" application with This isn't limited to MUSL; I'm actually using Finally: |
|
I'm going to reopen this issue, we'll probably need to figure out a few regressions when linking for |
apiraino
added
regression-from-stable-to-stable
|
For anyone stumbling upon this issue today, the equivalent of the stated |
`-Zdoctest-xcompile` started triggering rust-lang/rust#89626, and it's hard to fix the underlying issue.
Code
I received this pull request, which caught a regression for
aarch64-unknown-linux-muslwhen compiling for nightly. The same process works for stable and beta. I don't have a machine that can easily compile to this platform, so I can't reduce it at the moment: librasn/rasn#49Version it worked on
It most recently worked on: Works on stable and beta
1.56.0-beta.4 (e6e620e1c 2021-10-04)Version with regression
rustc --version --verbose: 1.57.0-nightly (0eabf25 2021-10-06)Backtrace
The text was updated successfully, but these errors were encountered: