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)

[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)

[messense]

This seems to happen again in rust version 1.79.0-nightly (8b2459c1f 2024-04-09)

 info: downloading installer
  Warning: Not enforcing strong cipher suites for TLS, this is potentially less secure
  info: profile set to 'minimal'
  info: default host triple is i686-unknown-linux-gnu
  info: syncing channel updates for 'nightly-i686-unknown-linux-gnu'
  info: latest update on 2024-04-10, rust version 1.79.0-nightly (8b2459c1f 2024-04-09)
  info: downloading component 'cargo'
  info: downloading component 'rust-std'
  info: downloading component 'rustc'
  info: installing component 'cargo'
  info: installing component 'rust-std'
  info: installing component 'rustc'
  
  info: default toolchain set to 'nightly-i686-unknown-linux-gnu'
    nightly-i686-unknown-linux-gnu installed - rustc 1.79.0-nightly (8b2459c1f 2024-04-09)
  
  
  Rust is installed now. Great!
  
  To get started you may need to restart your current shell.
  This would reload your PATH environment variable to include
  Cargo's bin directory ($HOME/.cargo/bin).
  
  To configure your current shell, you need to source
  the corresponding env file under $HOME/.cargo.
  
  This is usually done by running one of the following (note the leading DOT):
  . "$HOME/.cargo/env"            # For sh/bash/zsh/ash/dash/pdksh
  source "$HOME/.cargo/env.fish"  # For fish
  Install Rust toolchain nightly
  info: override toolchain for '/home/runner/work/rjsonnet-py/rjsonnet-py' set to 'nightly-i686-unknown-linux-gnu'
  info: downloading component 'llvm-tools'
  info: installing component 'llvm-tools'
/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

[messense]

Seems like this is happening again in nightly-i686-unknown-linux-gnu installed - rustc 1.82.0-nightly (3e9bd8b56 2024-08-08)

See PyO3/maturin-action#283 and https://github.com/Warthunder-Open-Source-Foundation/wt_blk/actions/runs/10321002590/job/28572852583#step:4:196

[weihanglo]

That was me overlooking it again: #14299

[weihanglo]

@messense should have been fixed via #14391 and rust-lang/rust#129066.
(Sorry I should have paid more attention to manual cargo update 🙇🏾‍♂️ )

[washanhanzi]

is it possible to temporarily pin openssl to 1.0.66? openssl has a vulnerability prior to 1.0.66, i don't know if this affect the cargo code base.

• PR in openssl
• rustsec

[weihanglo]

is it possible to temporarily pin openssl to 1.0.66?

I don't think so. [email protected] has a hard requirement of OpenSSL v3, and just one comment above you can see how convoluted it is for the bump (or how dumb I am 😞).

In Cargo we only call openssl::version::version(). None of our dependencies require openssl (only openssl-sys through libgit2-sys/libssh2-sys), so I doubt Cargo is affected.

[messense]

Note that this is happening again on rustc 1.87.0-nightly (794c12416 2025-02-21): https://github.com/PyO3/maturin-action/actions/runs/13468372295/job/37638469231

[weihanglo]

This was an overlook in #15166 and apparently we forgot to actually add openssl-sys to cargo package. The pinned version is under workspace.dependencies so it never really affect the dependency resolution.

The bad news is that #15166 is now in beta toolchain already. If we're going to fix this again we might need to revert it in beta as well.

[messense]

Better get it reverted before it reaches stable I think?

[weihanglo]

The OpenSSL v1 has been EOL for more than a year. Unsure the potential security implications of continuing with v1. I wonder how common an i686-unknown-linux-gnu image lacks for libatomic. I assume it is fairly common since some 32-bit CPUs don't have built-in atomic operations, and usually libatomic is packaged separately on those distros, right?

[bernd-edlinger]

Well, because of that I maintain my own openssl-1.1.1 feature branch with all necessary CVE fixes here:
https://github.com/bernd-edlinger/openssl
you are welcome to use it if you like.

[weihanglo]

Discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/openssl.203.20i686.20libatomic.

[weihanglo]

The Cargo team has discussed this issue in today's meeting. The root cause is convoluted, but can be seen as a bad interaction between Clang not providing built-in libatomic, and a bug in OpenSSL v3 that it doesn't use aligned intergers on 32-bit platforms.

Folks on Zulip have evaluated some possible solutions, and agree with that the most straightforward solution is requiring libatomic on 32-bit platforms when running Cargo.

libatomic is generally available in major Linux distributions. If you're seeing an error like this:

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

You could install libatomic through your system package manager.
See the list of libatomic on every distros: https://pkgs.org/search/?q=libatomic.