/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found

[binuengoor]

Error message: microbin: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by microbin)

This issue is happening after the latest code merge on July 25. Was never an issue before

[szabodanika]

That's really weird, I just did a release build on my personal server after merging #31 and #34 and everything is OK for me. Is there any further output you're seeing on build?

[binuengoor]

Nope. No errors on build. Also I'm using docker.

[ririinsta]

The same thing is happening to me however the only difference is I am using a raspberry pi.

[szabodanika]

I am using a raspberry pi 4 as well for my own server and developing on an M1 mac, tried building on a windows machine as well but can't reproduce this error. :/

[dvdsk]

(I do not use the docker build) The GLIBC version used by the docker container to build the executable could be different then the one of the system or docker container you end up running on. That could cause this.

It might be because your system or container downgraded its GLIBC version or the docker (build) container upgraded its.

Can you try running microbin in the same container as you build it?

I haven't tried it but this should do that:

# latest rust will be used to build the binary
FROM rust:latest as builder
# the temporary directory where we build
WORKDIR /usr/src/microbin
# copy sources to /usr/src/microbin on the temporary container
COPY . .
# run release build
RUN cargo build --release
# run the binary
CMD ["target/release/microbin"]

[binuengoor]

Just seeing the comment by @dvdsk . I did not get a chance to test the docker file update suggested by him. However from google I came to the same understanding.

I forked the repo and created a separate branch with code from jul 17. and it still works fine. Then I built one from the latest code and it have the same error. Not sure why its doing that. Nevertheless I finally got it working by updating the dockerfile with a different debian version.

Seems to be an issue with the debian image used to build the container. I changed the version from buster-slim to bullseye-slim and its working fine now.

https://packages.debian.org/buster/glibc-source buster is running glibc 2.28 bulleye is running 2.31

I found this from trial and error. so have no real knowledge about this. hope someone else can throw some light on this. I still dont know if its my system that have the 2.31 version or its the docker environment or rust or what. that part is totally over my head.

@szabodanika maybe this will help bring us closer to figure this out once and for good.

[dvdsk]

I still dont know if its my system that have the 2.31 version or its the docker environment or rust or what.

In this case (microbins docker file) there are two separate versions of glibc used but not that of your system. First docker builds the microbin exectable in the rust:latest container. Then it moved the executable to the buster-slim container (this saves you disk space as buster-slim is a lot smaller then rust:latest and it can now remove rust:latest).

Thanks to your experiment I am pretty sure the rust:latest container updated its glibc version beyond 2.28. Debian buster is an older release of Debian. I see no reason not to update the dockerfile to Debian bullseye like you do which fixes this.

You should put up a PR with your fix! :)

Edit: an alternative could be building microbin against musl, then microbin no longer depends on the system/containers glibc version. This would also make it easier to build microbin on one system and deploy it on another. At the same time one can wonder what value a container actually brings here, given microbin has no dependencies.

[binuengoor]

Edit: an alternative could be building microbin against musl, then microbin no longer depends on the system/containers glibc version. This would also make it easier to build microbin on one system and deploy it on another. At the same time one can wonder what value a container actually brings here, given microbin has no dependencies.

@dvdsk that sounds interesting. How can we accomplish that?

[dvdsk]

Normally it is enough to install the musl target (rustup target add x86_64-unknown-linux-musl) and tell cargo to use it: cargo build --release --target x86_64-unknown-linux-musl.

Microbin however has a few C dependencies that are build on compile using gcc. They normally link to Glibc now rust will try to use musl-gcc instead to link those to musl. For this it needs musl-gcc. On Ubuntu that is included in the package musl-tools (install it with: sudo apt install musl-tools.

Now we can build and the binary will appear: target/x86_64-unknown-linux-musl/release/.

Checking that it is completely statically linked and has no more dependencies on the system (except that it needs to have a Linux kernel and be x86_64): ldd target/x86_64-unknown-linux-musl/release/microbin we see: statically linked

On the normally build binary (not statically linked agains musl) ldd outputs:

linux-vdso.so.1 (0x00007ffd15f51000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc77cfd4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc77ceed000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc77cc00000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc77d6c4000)

[dvdsk]

Related news: https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html [not a cause of this issue, however I am putting it out here as it could be cause in the future if someone tries to run microbin without a musl build on pretty old systems released 8 or more years ago... Though no one should do that :) ]

[binuengoor]

this issue is fixed with the latest commit updating the dockerfile.