i686-unknown-linux-gnu/bin/cargo: error while loading shared libraries: libatomic.so.1

[messense]

Maintainer's note:

In Rust 1.87, Cargo in the official Rust distribution will have a hard dependency on libatomic on 32-bit platforms.

For more, see

• This comment for how to fix the error.
• This comment for the previous investigation.
• chore: bump openssl to v3 #15232

---

When running cargo in a quay.io/pypa/manylinux2014_i686:latest Docker container, it gives the following error

/root/.rustup/toolchains/nightly-i686-unknown-linux-gnu/bin/cargo: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Is libatomic.so.1 a hard requirement for cargo now?

Meta

rustc --version --verbose:

rustc 1.78.0-nightly (d18480b84 2024-03-04)

[messense]

Ah sorry, I meant to open this issue in rust-lang/cargo but ended up here by mistake.

[Noratrieb]

That is an old year in the image name. What's the glibc version? We only support kernel 3.2+, glibc 2.17+ as listed in https://doc.rust-lang.org/nightly/rustc/platform-support.html

[messense]

It's a CentOS 7 which has glibc 2.17, since it's running in Docker on Ubuntu 22.04, it should have a newer kernel version than 3.2.

# uname -a
Linux 2d9d45df5509 5.19.0-1029-aws rust-lang/rust#30~22.04.1-Ubuntu SMP Thu Jul 13 17:17:32 UTC 2023 i686 i686 i386 GNU/Linux

# rustc -vV
rustc 1.78.0-nightly (d18480b84 2024-03-04)
binary: rustc
commit-hash: d18480b84fdbf1efc34f62070951334aa833d761
commit-date: 2024-03-04
host: i686-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0

# # cargo
/root/.rustup/toolchains/nightly-i686-unknown-linux-gnu/bin/cargo: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

# # ldd /root/.rustup/toolchains/nightly-i686-unknown-linux-gnu/bin/cargo
        linux-gate.so.1 =>  (0xf7f0e000)
        libdl.so.2 => /lib/libdl.so.2 (0xf621c000)
        libatomic.so.1 => not found
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf6201000)
        librt.so.1 => /lib/librt.so.1 (0xf61f7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf61dc000)
        libm.so.6 => /lib/libm.so.6 (0xf619a000)
        libc.so.6 => /lib/libc.so.6 (0xf5fcf000)
        /lib/ld-linux.so.2 (0xf7f10000)

# ldd --version
ldd (GNU libc) 2.17

[messense]

cc @weihanglo in case you know something about this.

[messense]

For comparison, Rust stable (1.76.0 ATM) works fine:

# ~/.rustup/toolchains/stable-i686-unknown-linux-gnu/bin/cargo -vV
cargo 1.76.0 (c84b36747 2024-01-18)
release: 1.76.0
commit-hash: c84b367471a2db61d2c2c6aab605b14130b8a31b
commit-date: 2024-01-18
host: i686-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.5.0-DEV (sys:0.4.70+curl-8.5.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: CentOS 7.0.0 [32-bit]

# ldd ~/.rustup/toolchains/stable-i686-unknown-linux-gnu/bin/cargo
        linux-gate.so.1 =>  (0xf7f2a000)
        libdl.so.2 => /lib/libdl.so.2 (0xf6156000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf613b000)
        librt.so.1 => /lib/librt.so.1 (0xf6132000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf6116000)
        libm.so.6 => /lib/libm.so.6 (0xf60d4000)
        libc.so.6 => /lib/libc.so.6 (0xf5f09000)
        /lib/ld-linux.so.2 (0xf7f2c000)

[weihanglo]

This is the bad Cargo submodule update rust-lang/rust#121214. It is very likely that OpenSSL v3 did something differently than v1.

[weihanglo]

Probably this openssl/openssl#23376?

[weihanglo]

sfackler/rust-openssl#2163 and I mentioned it earlier in #13449 (comment)
(I forgot everything older than three days ago)