ELF binary built linked against fake loader #102993
Comments
|
See #82519 I think. |
|
What linker did you tell rustc to use for AArch64? You need to use a gcc or clang for cross-compiling to aarch64+musl, not one for aarch64+glibc. |
|
@bjorn3 I am not cross-compiling, I'm just running |
|
My bad. What does |
|
@bjorn3 Here you go: |
|
The issue tracker is not a support forum. For future questions please ask in one of these places: https://discord.gg/rust-lang/ I suspect your current issue is a problem with your default linker, not the compiler itself. |
|
For the record, I only posted this issue here after discussing it in the rust matrix chat, where I was told (after some group investigation) that it looked like a bug in cargo or rustc. |
|
Ok. You can use |
|
I just hit this as well. To be clear, no cross-compiling is involved. Both host and target are It seems to be triggered by external C library deps that cause the binary to be dynamically linked (rather than static as would be the default for Here's an example of reproducing it by linking apk add build-base curl curl-dev pkgconf
curl https://sh.rustup.rs -sSf | sh -s -- -y
. ~/.cargo/env
cargo init --bin tester
cd tester
cargo add curl
echo 'use curl::easy::Easy; fn main() { Easy::new(); }' > src/main.rs
cargo buildRunning the resulting binary fails: # target/debug/tester
/bin/sh: target/debug/tester: not foundThe loader is wrong: # ldd target/debug/tester
/lib/ld-linux-aarch64.so.1 (0xffffa0b61000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0xffffa0ace000)
libnghttp2.so.14 => /usr/lib/libnghttp2.so.14 (0xffffa0a8d000)
libssl.so.3 => /lib/libssl.so.3 (0xffffa09e9000)
libcrypto.so.3 => /lib/libcrypto.so.3 (0xffffa0663000)
libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0xffffa0642000)
libz.so.1 => /lib/libz.so.1 (0xffffa0611000)
libc.musl-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 (0xffffa0b61000)
libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0xffffa05e0000)
# ls /lib/ld-linux-aarch64.so.1
ls: /lib/ld-linux-aarch64.so.1: No such file or directory |
|
@jbg do you have the same issue in a standalone C problem that links against curl? If so, this isn't a bug in the compiler itself. If not, you may want to talk to the owners of the curl crate on crates.io, there are various flags build scripts can pass that affect how the final program is linked. You can use |
Does setting |
|
No, linking isn't broken in Alpine in general, it's only Rust that has this issue. The |
|
@bjorn3 yes, setting $ RUSTFLAGS="-Ctarget-feature=-crt-static" cargo build
[...]
Finished dev [unoptimized + debuginfo] target(s) in 10.89s
$ ldd target/debug/tester
/lib/ld-musl-aarch64.so.1 (0xffff928d0000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0xffff927cc000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xffff9279b000)
libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0xffff928d0000)
libnghttp2.so.14 => /usr/lib/libnghttp2.so.14 (0xffff9275a000)
libssl.so.3 => /lib/libssl.so.3 (0xffff926b6000)
libcrypto.so.3 => /lib/libcrypto.so.3 (0xffff92330000)
libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0xffff9230f000)
libz.so.1 => /lib/libz.so.1 (0xffff922de000)
libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0xffff922ad000) |
|
Does |
|
After installing the various required static libraries and amending the command to link them, gcc still produces a binary with the correct loader: |
|
The rust linker invocation when building the above example program with the
Guessing at the problematic bits, I was able to recreate the same issue with the |
|
FWIW, folks on #musl IRC say that rust is invoking the linker in a broken way here by using Maybe trying to dynamically link should be an error if the |
|
That nakes sense.
At the very least it should he a warning pointing you to |
|
Is it possible for the default of I can understand the motivation for making |
|
There is an MCP to move *-musl to dynamic linking by default, but it isn't actually implemented yet and will need some care to notify everyone currently using musl for static linking. rust-lang/compiler-team#422 |
|
#59302 is relevant |
jyn514
added
A-linkage
|
The root cause seems to be here: rust/compiler/rustc_codegen_ssa/src/back/link.rs Lines 2478 to 2482 in ad23942 If no |
|
Is there any reason why Rust can't link binaries dynamically by default on *-unknown-linux-musl like it does on *-unknown-linux-gnu? It seems weird that the behaviour for one libc is different to the other, and the norm on Linux is to dynamically link libraries. |
hi, I'm compiling a Rust program on my ARM AArch64 machine which is running linux with a musl libc. Rust wants to compile the binary with the interpreter set as
/lib/ld-linux-aarch64.so.1which does not exist on my system. I do have/lib/ld-musl-aarch64.so.1however.As a result when I try to execute the binary built by rust in this case I just get ENOENT. In fact when I
strace ./binarythere is only a single syscall printed, the execve on the binary itself, which returns ENOENT. This makes me sad...Manually loading the binary (ie running
exec /lib/ld-musl-aarch64.so.1 $PWD/binary) gets me a lot farther in the execution of my program which then crashes for other reasons, presumably my fault :) But that's out of scope for this issue.If it helps I installed Rust via rustup.
The text was updated successfully, but these errors were encountered: