Find a reliable methd of resolving the glibc version

[azubieta]

Currently we use gnu_get_libc_version to find the glibc version. This method requires a dynamically linked AppRun to work properly and this is a impediment when the target system doesn't have glibc (like in an alpine based system).

A different method is required that allows static linking of the main binary.

reference: https://stackoverflow.com/questions/71070969/how-to-extract-and-compare-the-libc-versions-at-runtime

[azubieta]

Proposed solution:

• Store version definitions for embed libraries at build time.
• Compare definitions with the ones on the host system libraries, use the system one if all definitions are found.

Reference

• http://ftp.ntu.edu.tw/software/libs/glibc/hjl/compat/
• https://maskray.me/blog/2020-11-26-all-about-symbol-versioning

[probonopd]

A bit hackish, but searching with strings <file> | grep GLIBC_ | sort | uniq usually gives an indication. It's what I always do when I have to find out the required glibc version manually.

[azubieta]

We used that method in AppRun v1 but it failed when new symbols get added like between glibc 2.30 and 2.32.

[probonopd]

How can that be? Did they add symbols without increasing the GLIBC_ number?

[azubieta]

They added other symbols that are not versioned with the GLIBC_ prefix.

[probonopd]

Ouch. Just as an idea, if we have two libs with the same highest GLIBC_ number, could we count the number of symbols in both and assume the one with more symbols is the newer one? A bit hackish but might get the job done?

[azubieta]

I have been comparing symbols from different libraries but they add and remove symbols as they will. Those removed are private symbols that "should" not be linked but they may end linked if the developer requires it so it's a big mess there.

As there is no solution in which we could rely at 100 I decided to different detection methods like guessing the version from the file name or reading it from the embed strings. This will live in a separated executable that performs the checks and report back to the AppRun. So the AppRun can stay static. Also will add some environment variables to manually control which configuration should be used.

[probonopd]

Maybe the topic should be discussed with the glibc devs?

[azubieta]

Maybe the topic should be discussed with the glibc devs?

I did it already, their answer is was precisely to use gnu_get_libc_version. Other ways are just guessing. For libstc++ the problems is more complicated as they don't provide a function retrieving the version.