Incompatible libstdc++ version with base image

[jdoubleu]

I'm not sure if this is really an issue, but I noticed, that the libstdc++ version in this image is newer than in the base image (debian).

Take gcc:11 for example: It uses buildpack-deps:bullseye as base image, which is just debian:bullseye with build tools as far as I understood.

However, when I'm trying to run a binary, built using this image, let's say in debian:bullseye, I get the following error:

./my_bin: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./my_bin)
./my_bin: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by ./my_bin)

That is correct, because the latest version present in current debian:bullseye is:

$ docker run --rm -it debian /bin/sh -c 'apt update && apt install -y binutils; strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX'
...
GLIBCXX_3.4.28
GLIBCXX_DEBUG_MESSAGE_LENGTH

It seems like gcc used its own libstdc++:

$ docker run --rm -it gcc /bin/sh -c 'strings /usr/local/lib64/libstdc++.so.6 | grep GLIBCXX'
...
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_DEBUG_MESSAGE_LENGTH

The file /usr/local/lib64/libstdc++.so.6 does not exist in debian:bullseye , found a reference in gcc:11 here:

gcc/11/Dockerfile

Line 144 in c2c4e3a

# gcc installs .so files in /usr/local/lib64 (and /usr/local/lib)...

Workaround

One way to make the binaries work in other environments would be to explicitly pick a libstdc++ version with -fabi-version=n.

Alternatively, you could just use the gcc:10 image:

$ docker run --rm -it gcc:10 /bin/sh -c 'strings /usr/local/lib64/libstdc++.so.6 | grep GLIBCXX'
...
GLIBCXX_3.4.28
GLIBCXX_DEBUG_MESSAGE_LENGTH

Again, I'm not sure whether that's an issue which should be solved by this repo/image. I could only imagine people using multiple standard docker images. The root cause is probably that debian doesn't catch up with the newest gcc releases, which they cannot to be fair. In the end, that's what you get for using the latest or bleeding edge technology.

[tianon]

Yeah, the goals of Debian and this image are a little bit at odds here -- the purpose of this repository is to provide the latest up-to-date bleeding edge versions of GCC (on an otherwise stable distribution base), so the behavior you've described is somewhat "working as expected", I'm afraid.

If you want to be able to build dynamic linked binaries that work in a stock Debian base, you probably want buildpack-deps. If you want to be able to use the latest bleeding edge GCC features (perhaps new versions of the C++ spec, for example), then this image is an option, but you'll need to either plan to bring along the appropriate libraries or compile them into your binary statically.

[jdoubleu]

Thanks for the quick response!

I'm going to stick to the gcc:11 image then.

At least it is now sort of documented, if anyone else stumbles upon this issue.