v1.0.31 binary shared object issue

[kapsakcj]

Hi guys,

I'm making a new docker image that uses the pre-compiled binary tarball that accompanies the GitHub release. When running the included test_stxtyper.sh script it's giving me this error:

$ bash test_stxtyper.sh 
Testing ./stxtyper
  To test stxtyper in your path run 'test_stxtyper.sh path'
./stxtyper: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./stxtyper)

When I try to print the version info, I get the same error:

$ ./stxtyper --version
./stxtyper: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./stxtyper)

I haven't seen this error with previous versions of stxtyper and a nearly identical dockerfile/docker image so I'm wondering if something is different about this pre-compiled binary.

Any suggestions on how to resolve this? My knowledge of this kind of compilation & shared object stuff is pretty limited...

[kapsakcj]

maybe this helps explain the issue? I'm using ubuntu:jammy as the base docker image

$ strings /lib/x86_64-linux-gnu/libstdc++.so.6 | grep "GLIBCXX"
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH

[kapsakcj]

Hmm, perhaps we can close this issue.

I resolved the error by upgrading the base docker image to a more recent release of Ubuntu, ubuntu:noble and the error went away and all the tests passed as expected.

I guess this more recent version of ubuntu supports more recent versions of GLIBCXX? I don't really know what's going on here, but thought I'd let you all know. This is from the ubuntu:noble base docker image:

$ strings /lib/x86_64-linux-gnu/libstdc++.so.6 | grep "GLIBCXX"
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_3.4.31
GLIBCXX_3.4.32
GLIBCXX_3.4.33
GLIBCXX_TUNABLES
GLIBCXX_DEBUG_MESSAGE_LENGTH

[evolarjun]

Thanks Curtis, glibc version issues are annoying. You likely will have the same issue with AMRFinderPlus 4.0.15 which we also just released. I'm not sure what the best practice is for the version of glibc to link against. Maybe try linking to an older version or I guess creating a static binary? If you have recommendations on how we should build our binaries for distribution please let me know.

[kapsakcj]

🤷 Thanks for the heads up about amrfinderplus, I'll likely upgrade to the more recent ubuntu base image there as well.

I don't know how to link glibc versions and I'm fine with just upgrading the base image/OS used in the docker container as it shouldn't impact functionality of stxtyper or amrfinderplus.

No recommendations at this time but I'll let you all know if any other issues pop up in the future.

Thanks!

[evolarjun]

I did some googling, and I think I may be able to fix this issue in the future by just statically linking libstdc++ with the -static-libstdc++ option (branch staticlink_libstdc). I'm not 100% sure that will work because I have limited experience with just statically linking a single library, but I'm going to try that.

I'll try to run some tests with older OSs, but I don't have time to do it now.

I'm reopening this issue to remind me to do the testing and modify the build process for AMRFinderPlus as well if that does fix the issue without causing other problems. Maybe I should just statically link everything?

[kapsakcj]

OK, worth a try I guess? Not high priority for me since I already have a workaround but I appreciate you looking into it more

Again I'm really out of my depth here but perhaps for quick testing on older OSs, it's easy to swap in base images used in dockerfiles to test with newly-built-statically-linked binaries.

Feel free to try it out with the dockerfile here: https://github.com/StaPH-B/docker-builds/blob/master/build-files/stxtyper/1.0.27/Dockerfile

Some modification of the dockerfile will be needed to bring in the new binaries, perhaps using the COPY dockerfile instruction

My first thought was to see how samtools handles this stuff, as they have a super broad user base with diverse compute platforms. Though it's written in C, not C++ (likely showing my naivety 😅 ) https://github.com/samtools/samtools/blob/develop/Makefile

[evolarjun]

It looks like samtools only provides the source (maybe I'm wrong). If you build it on the target system then linking against different versions of libstdc++ or libc isn't a problem. The way it works now for StxTyper is just that I build the distribution binary on whatever dev server I'm working on. It's simple and manual. I'm hesitant to make things more complex if I don't have to.

I had considered making docker images that compile from source (compiling from source in a parent build container then copying the binaries into the release image), but I got lazy and just copying in the binaries was easier.