[Bug dynamic-link/22825] Implement multiarch ldconfig

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22825

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
There is no need for multiarch names to implement multiarch ldconfig.  At 
least, there is no need for such names for the first several minimal 
incremental patches in a consensus-driven patch series aimed at improving 
multiarch ldconfig support as part of the "eliminate differences between 
cross-compiling and native compilation of glibc" project.

For example, suppose the ldconfig cache were to contain information about 
the e_machine value, e_flags value, EI_CLASS value (32-bit or 64-bit) and 
EI_DATA value (endianness).  Then most of the machine-specific flags 
currently present in the cache would be obsolete because all the required 
information could be deduced from them.

So it would be possible to have an incremental patch that adds *just one* 
of those pieces of information to the cache, removing or updating just 
those pieces of architecture-specific code for which such an update is 
appropriate after such a change.  Such an incremental patch should cause 
no change whatever to which libraries are actually accepted by the dynamic 
linker based on cache information on any platform, and should keep 
ldconfig working with all the libraries it works with at present on every 
platform.  If such a patch were to achieve consensus, it would be possible 
to go on to the next patch, adding one further such bit of information to 
the ldconfig cache.

Is it desirable to have all that information in the ldconfig cache, or 
does it deliberately collapse e.g. different e_flags values with the same 
ABI into a single piece of information in the cache?  I don't know.  It's 
for the person making such a change to look into such questions and 
explain why adding particular information to the cache is safe, if it is - 
not to assert it is, not to ignore the question, but to look into it, 
mention it explicitly and discuss the arguments both ways.  What would 
happen to the code printing ldconfig flags?  I don't know - maybe it would 
extract information from e_flags etc., maybe it wouldn't - that's for the 
patch explanation to justify.

If ldconfig were to reach the point of having that information in the 
cache (so likely eliminating much of the need for machine-specific 
readelflib.c files), one might then look at other ways in which ldconfig 
involves machine-specific code, and, one at a time, seek to eliminate 
those machine dependencies.  For example, one incremental patch might add 
ldconfig support for reading other-endian libraries (and do nothing else 
at all).  One might make the cache itself endian-independent (and do 
nothing else at all).

Nothing involves multiarch names, because the ABI distinctions already 
exist at the binary level (e_machine, e_flags etc.).

If any ABI distinction at <https://sourceware.org/glibc/wiki/ABIList> is 
not represented in the ELF information listed above, one might then work 
with the GCC and binutils communities, and any upstream definition of the 
architecture ABI, to add that information to e_flags.

If any ABI distinction is represented in the ELF information but not 
currently used in _dl_cache_check_flags, elf_machine_matches_host etc. to 
check compatibility, one might add such more precise checks to those 
places, one architecture at a time.

It's still the case that none of this needs multiarch names - and none of 
it, done one small piece at a time, always seeking whole-community 
consensus and always making sure to explain the strongest possible version 
of the arguments *against* the approach you are taking, should be 
especially controversial.

-- 
You are receiving this mail because:
You are on the CC list for the bug.