-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undefined reference to getauxval
in function init_have_lse_atomics
when compiling to nightly aarch64-unknown-linux-musl
#89626
Comments
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 |
forcing notification for prioritization @rustbot label -I-prioritize +T-compiler +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 run This 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 |
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.
This doesn't seem to be a problem for me any more since 9ed0d11. |
Code
I received this pull request, which caught a regression for
aarch64-unknown-linux-musl
when 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: