Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz <matz@suse.de>]

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.