Rust Linux Version Glibc Not Found - Compile for Different Glibc/Libc6 Version

Rust Linux version glibc not found - compile for different glibc / libc6 version

Per the issue: https://github.com/rust-lang/rust/issues/57497 - there's no way to tell the Rust compiler to link a different library other than the one installed on the system.

This means I have to compile the binary on a system that has a less recent version of libc6 installed - then the binary should be compatible with the same version of libc6, or a more recent version*

The most convenient way of doing that would by using a Docker image that has the target libc6 version and rustup.

For myself, the official Rust docker image had the correct version I could use to compile for my target.

In the working directory:

sudo docker pull rust
sudo docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust cargo build --release

If the official image, which is based on Debian does not satisfy the version requirement, you will have to create a custom docker image, i.e.:

• fork the official Rust docker image and set it to use an older version of Debian
• or create an image that is based on an older Debian or other Linux distro image and configure it to install rustup

* I could use a binary compiled with libc6 2.31 on a system that has libc6 2.32 - I'm not sure how far backwards compatibility goes.

Build and bind against older libc version

If your project does not depend on any native libraries, then probably the easiest way would be to use the x86_64-unknown-linux-musl target.

This target statically links against MUSL Libc rather than dynamically linking against the system's libc. As a result it produces completely static binaries which should run on a wide range of systems.

To install this target:

rustup target add x86_64-unknown-linux-musl

To build your project using this target:

cargo build --target x86_64-unknown-linux-musl

See the edition guide for more details.

If you are using any non-rust libraries it becomes more difficult, because they may be dynamically linked and may in turn depend on the system libc. In that case you would either need to statically link the external libraries (assuming that is even possible, and that the libraries you are using will work with MUSL libc), or make different builds for each platform you want to target.

If you end up having to make different builds for each platform, a docker container would be the easiest way to achieve that.

GLIBC incompatibility on debian docker

If you look at the list of Debian releases, as of this writing Debian 10 "Buster" is one release behind, and Debian 11 "Bullseye" is the current released stable version. You can also look at the libc6 package listing and see that "Buster" contains libc6 2.28, and "Bullseye" contains libc6 2.31 (both with local patches).

So for your setup, it should work to change the final image to a newer version of Debian, like

FROM debian:bullseye-stable # one newer than buster

error /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found

ITs works for me when i avoid /target directory and now working both version of ubuntu 20.04 and 21.10. Giving thanks to @Charles Duffy and @Herohtar for their important and useful instruction,

FROM ubuntu:21.10
RUN apt-get update && apt-get upgrade -y
RUN apt-get install libssl-dev

RUN apt-get install -y -q build-essential curl
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
ENV PATH="/root/.cargo/bin:${PATH}"

WORKDIR /command-agent
COPY ./src/. /command-agent/src/
COPY .env /command-agent/
COPY Cargo.toml /command-agent/
COPY Cargo.lock /command-agent/
RUN cargo build --release

EXPOSE 8080
ENTRYPOINT /command-agent/target/release/command-agent

version `GLIBC_2.28' not found

So is it possible to install GLIBC_2.28 on my machine?

It is possible, but the chances of you making a mistake and rendering your system un-bootable are quite high. It is also very likely that doing so will break something else on your system (this is the reason distributions do not usually update the version of GLIBC from the one they originally shipped with).

A much better solution is to built PyTorch targeting your system (i.e. using your "normal" toolchain).

P.S. GLIBCXX has nothing to do with your problem, and just adds noise to your question.

---

Related Topics