James Addison <j...@jp-hosting.net> writes: > We've almost certainly all encountered limitations in upstream > specifications and wondered when it's worth attempting a perceived > improvement despite potential friction.
> If Debian did want/need to change the PT_INTERP path, is there a way to > achieve that in both a standards-compliant and also a distro-compatible > way? My recollection is that we considered this when starting with multiarch but none of the other distributions outside of Ubuntu were very enthused, so we dropped it. I saw those discussions on the glibc development lists, which is not really the place for detailed x86_64 ABI discussion but which would certainly be an interested party and has roughly the right people present. If I saw a problem that would need to be addressed with an ABI change and didn't have anyone else to ask, that's where I personally would start, but the Debian gcc and glibc maintainers would probably know more. The bar for justifying a change will be fairly high, based on past discussions. I would expect it to require some sort of significant bug that can't be worked around in another way. > Although tests may not exist publicly in this case, the idea of using > tests where possible to catch regressions seems relevant to me. Tests > can help people to identify when a compatibility boundary has been > reached or overstepped, and, socially, they can provide a clear place to > gather discussion if & when they become outdated (particularly if the > tests are themselves are provided free and open source). Copying > binaries and running them seems like a form of testing, but perhaps we > could find better ways. I don't know if anyone has written an ABI compliance test for binaries. That sounds like something that would be in scope for the Linux Test Project, though, and it's possible their existing tests do some of this. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
