Hi, On Fri, 26 Jan 2018, Javier Serrano Polo wrote:
> It would be nice if you answered the question about appendix A.1. > > So, we have five people who state or imply that either my amd64 systems > do not exist or they are unavoidably incompatible with systems depending > on a /lib64 directory. > > My systems obviously exist. To the claim that I cannot run a /lib64 > program without rebuilding, the answer is easy to say: try my system. To > the claim that applications from my system will not run anywhere else, I > can provide a counterexample: you can install the attached package. > > Would you accept the evidence? Is /lib64 still a mistake or rather a > maintainer's choice? Just because your system works fine with deviations from the psABI (as it contains code or data to make it work with these deviations) doesn't imply that any changes in the psABI are required or advised. To see why that is so suppose I'm changing my compiler to use a different calling convention in which the first argument is passed in %rsi and the second in %rdi, and otherwise it's all the same. I recompile my whole system and I adjust all the various assembler snippets that have it hard-coded. I will end up with a system that works fine; just like you. Does it make sense to encode this new calling convention in the psABI? No. The whole point of a defined psABI is that you can move an executable from one compatible system to another different but also psABI-compatible system and rightfully expect that to work (given further constraints, of course). Encoding alternatives for the dynamic loader into the psABI defeats this purpose. A psABI-compliant system then suddenly wouldn't only have to provide /lib64/ld-linux-x86-64.so.2, but also your proposed file; i.e. alternatives in an ABI are actually additional requirements on the system (they're alternatives only for a particular file). If a system wouldn't do that then it can't claim to be psABI-compatible anymore as there would exist executables which can't be loaded on it. So, while you might say that putting the loader into an alternative path is a maintainers choice, it's a (badly advised) maintainers choice of not following the psABI, not a good reason to change it. This is slightly different from the choice of not following the suggestion in the psABI of putting libraries into **/lib64, like the multiarch approach is doing. It is different because these path names are configurable as search paths in the loader configuration files (and were already configurable at the time multiarch was invented) and not directly encoded into the ELF files. (Ignoring DT_RPATH and DT_RUNPATH of course). So, no, we can't change the psABI in that respect without repercussions for all systems claiming to be conforming, which is a bad idea for an ABI that's already nearly 20 years old. Ciao, Michael.