Re: Policy: Require new dynamic loader names for entirely new ABIs?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 23 Jan 2014, Steve McIntyre wrote:

>  * Could/should we change ldconfig to deal with all the ELF libraries
>    it finds in the system search paths, regardless of architecture and
>    ABI? I see nothing inherently difficult with this: all the ELF
>    header parsing code is already portable and AFAICS it shouldn't
>    care at all about the platform of the libraries it finds.

I'm sure in principle this could be done - taking all the 
architecture-specific code to identify ABI variants and putting it 
somewhere central, much like elf.h is a central file with information on 
all architectures.  I'm not sure how simple it is, however.  See the 
comments on cross-ldconfig at 
<https://sourceware.org/glibc/wiki/Development_Todo/Master#Cross_build_.2BAC8_test_improvements>.  
It could be that changing the code to be multi-arch friendly would be 
simpler than building cross-ldconfig under constraints to avoid large 
changes to the underlying code.

(And some ABIs don't currently have any good way to distinguish them 
through the ELF headers, e.g. powerpc soft-float / hard-float, so would 
need to share a cache until appropriate ELF header flags are defined and 
implemented.)

>  * Should we then split the cache up into multiple files, one per
>    arch/ABI? (In fact, one per distinct loader?) This would remove any
>    potential issues with collisions and should make things simpler and
>    maybe faster as far as I can see - in multiple-ABI cases each
>    loader will have a smaller search space when looking for libraries.

ldconfig will, for relevant architectures, handle libc4/libc5 libraries as 
well as those built with glibc.

We need to avoid breaking running binaries built with those libraries, 
although we don't need to optimize anything for them.  Did they require 
the cache to be present in order to find libraries (rather than it simply 
being an optimization)?  If so, that may limit the changes that can be 
made, because ld.so.cache will need to remain usable by libc4/libc5, 
although glibc could certainly stop reading it, instead using newer files, 
and I suppose ld.so.cache could contain *only* the data needed by the old 
libraries (i.e. information about same-architecture libc4/libc5 files).  
See sysdeps/generic/dl-cache.h, "libc5 and glibc 2.0/2.1 use the same 
format.  For glibc 2.2 another format has been added in a compatible way 
..." for information on existing compatibility handling.

Now, it appears some support for libc4/libc5 is present unconditionally 
rather than only for (the Linux kernel with) architectures needing it.  
If ldconfig is to be properly multi-architecture, I suppose that makes 
sense, however unlikely it is to be running such binaries via emulation on 
another architecture, but otherwise it might be conditioned out.  
Specifically, it's only relevant for m68k and i386, and x86_64 and maybe 
ia64 for running i386 binaries; libc4 and libc5 didn't support other 
architectures.

-- 
Joseph S. Myers
joseph@codesourcery.com