Luca Boccassi <bl...@debian.org> writes: > Why would "software compiled on Debian" fail to work in other > environments? Well, there are many reasons actually, people invented > containers/flatpaks/snaps exactly for that reason. But nothing do with > anything discussed here though, as far as I can tell?
My understanding is that this specific thread is about a mention that we may want to change PT_INTERP to /usr/lib64/ld-linux-x86-64.so.2 or some similar path. If PT_INTERP points to a file that doesn't exist, the program is obviously not going to run. The Linux x86_64 ABI says it must point to /lib64/ld-linux-x86-64.so.2. If we build binaries that use some other value, then we are not building ABI-compliant binaries and they may not run on other systems. This is the whole point of an ABI. An obvious specific example of such a system would be one that didn't merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other path, but that's just one obvious example. There may be others; the whole point of an ABI is that you do not change things like this, not even if you can't personally imagine why your change wouldn't be harmful. There's a whole process for changing an ABI that involves everyone else agreeing as well, and unless one goes through that process, the ABI is what it is. Debian not building ABI-compliant binaries would be highly surprising. Incidentally, that remains true even if we only do that in distribution packages. I certainly have copied binaries from a Debian package to other Linux systems before for various reasons and expected them to run. Sure, this might not work for other reasons outside of our control, but that's no reason to be gratuitously incompatible by breaking the ABI, particularly for what seem to be annoyances of our own creation with known workarounds. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
