5 ms·
glibc has so far managed to guarantee backwards compatibility going back to every version that has offered libc.so.6 (which goes back two decades!). They explic
by Conan_Kudo 5y ago
glibc has so far managed to guarantee backwards compatibility going back to every version that has offered libc.so.6 (which goes back two decades!). They explicitly guarantee that backward compatibility: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
- AnIdiotOnTheNet 5y agoOk, is there a way to say "please compile my binary such that it will work with the oldest version of glibc"? I mean, other than to locate a copy of a distribution with a glibc that old to build on.
- marcan_42 5y agoNot using new features will usually do that, but I wonder what's up with the math stuff pulling in symbol versions from 2018. There should be an explanation for that one...
- AnIdiotOnTheNet 5y agoSure, but is there any convenient mechanism to ensure that you don't use new features? I guess what I'm asking is, why does glibc not make this easier to do?
- spystath 5y agoI think the generally accepted way to do that would be a container image running a relatively old distribution. This is exactly what python packages do when they need to distribute binary packages on linux [0]. You are supposed to compile the package in a container (or VM) that runs CentOS 7 (or older if you want broader support), although now the baseline is moving gradually to Debian 9. [0]: https://github.com/pypa/manylinux https://github.com/pypa/manylinux
- AnIdiotOnTheNet 5y agoSo round about, the answer is a firm "no".
- Conan_Kudo 5y agoI think you can pass a linker flag to make it use the oldest version of each symbol, but I'm not sure what that flag is.
- severino 5y agoI remember you could decide which glibc version, for some specific symbol, you wanted to use. For example, if you wanted to make your program use the "realpath" version from glibc 2.0, instead of the current one, you could do something like this: __asm__(".symver realpath,realpath@GLIBC_2.0"); So, even if the glibc version in the build system is more modern (lets say 2.3), your code will also work with older ones, such as 2.0.
- AnIdiotOnTheNet 5y agoIs there a way to do that for every symbol? I'm asking because from what I've read from developers the only reliable way to do this is to compile on an old distribution with an old libc. So either there are problems with using this method or it is very poorly documented.
- severino 5y agoI haven't found a way, although I never had the need. I remember you could compile your software targeting a specific LSB release, and there were some tools to do that, but I don't know if it would be the same.