Repository navigation
wrong libc linked during build #6582
Description
Activity
- addedA-linkageArea: linker issues, dylib, cdylib, shared libraries, soArea: linker issues, dylib, cdylib, shared libraries, so
on Jan 31, 2019 - changed the title
[-]cargo install no longer works after Rust updates[/-][+]wrong libc linked during build[/+]on Jan 31, 2019 I have the same problem.
But it seems to be rust issue because cargo 1.31.1 with rustc 1.32.0 can't fix it.
I created a new issue:
rust-lang/rust#58394The cause of this issue seems to be below:
libserde_derive-615594b83ebc865a.sois linked bycc. In linuxbrew environment,ccbecomes~/.linuxbrew/bin/ccbyPATHenvironment variable. Thereforelibserde_derive-615594b83ebc865a.sois linked to~/.linuxbrew/lib/libc.so.6.- rustc loads
libserde_derive-615594b83ebc865a.sobylibc::dlopen. The official rustc fromrustupis linked to/lib64/libc.so.6, solibc::dlopenuse/etc/ld.so.(config|cache)as library search path. Thereforelibc::dlopenis failed because~/.linuxbrew/lib/libc.so.6can't be found.
There is a workaround that change
ccto/usr/bin/cc.
If~/.cargo/configis below, default linker becomes/usr/bin/cc, so this issue can be resolved.[target.x86_64-unknown-linux-gnu] linker = "/usr/bin/cc"
Reacted by Ishaan GuptaThis will lead to another problem when i tried to compile rust-zmq
error: linking with `/usr/bin/cc` failed: exit code: 1 | = note: "/usr/bin/cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" ... = note: /home/linuxbrew/.linuxbrew/bin/ld: //home/linuxbrew/.linuxbrew/lib/libstdc++.so.6: undefined reference to `__cxa_thread_atexit_impl@GLIBC_2.18' collect2: error: ld returned 1 exit statusSo i was wondering how to compile rust with linuxbrew glibc?
Reacted by Nick Reynolds Tran and zhaozhongshuNow I have another workaround.
Ifcargocommand is defined like below, all linkers and compilers called bycargobecome/usr/bin/cc.
This example is zsh function. If you use another shell, some modification may be required.function cargo() { PATH=~/.cargo/bin:/usr/bin:/bin command cargo $@ }Reacted by Tom SaegerI have a similar problem:
/app # rustup default 1.45.2-x86_64-unknown-linux-musl (default) /app # cargo run --release --target x86_64-unknown-linux-musl --bin server Finished release [optimized] target(s) in 0.92s Running `target/x86_64-unknown-linux-musl/release/server` error: could not execute process `target/x86_64-unknown-linux-musl/release/server` (never executed) /app # ldd target/x86_64-unknown-linux-musl/release/server /lib/ld64.so.1 (0x7f6ee00f0000) libssl.so.1.1 => /lib/libssl.so.1.1 (0x7f6ee006f000) libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7f6edfdf0000) libc.musl-x86_64.so.1 => /lib/ld64.so.1 (0x7f6ee00f0000) /app # cargo --version cargo 1.45.1 (f242df6ed 2020-07-22) /app # rustc -V rustc 1.45.2 (d3fb005a3 2020-07-31)The problem is that
/lib/ld64.so.1doesn't exist in the system (alpine 3.12) and despite i specified a musl target it still linked with/lib/ld64.so.1. Workaround which worked for me is to copylibc.musl-x86_64.so.1to/lib/ld64.so.1.Possibly related fix for this in #9322.
- addedS-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.
on Oct 31, 2023
Problem
It's been just two months I have not touched Rust but today after upgrading to the most recent version I was no longer able to use
cargo install.Steps
rustup update+rustup default stablecargo install ripgrepat the end of compilation the error message shows up:
I think the problem happens at linking time so I don't know if the additional error message at the end was really helpful.
This should not happen because
rustcis not supposed to link against/usr/lib64/libc.so.6:and
/home/linuxbrew/.linuxbrew/lib/libc.so.6is an updated version of glibc:Notes
Output of
cargo version:The platform I have is CentOS 7. And if I downgrade rust to 1.31.0, it works without any problem. So this should be related to the version update.