[PATCH] nptl: proper soname handling

[Michael Deutschmann]

On Thu, 22 Apr 2010, Timo wrote:
> This really is configuration management issue, and doable inside a single
> distribution.

I don't understand what "configuration management" means.  Perhaps this
is why I don't quite get you and Natanael...

Basically, my point is that in general, changing the soname is only of
value to enable side-by-side.  But in the case of the C library itself,
changing the soname is far from sufficent, because there is no easy way to
modify the sonames of every dependent shared library (ncurses, readline,
bfd) so as to avoid collision.

The distinction between libc.so.6 (Glibc) and libc.so.0 just barely
works, and only because of special magic in ldconfig.  If you want to
support a libc.so.0 to "libc.so.0.1" rollover in the same way, you'll need
to also add LIB_ELF_LIBC0_1 to ldso/include/dl-defs.h, and then ring the
changes through ld.so and ldconfig.

(Seeing as uClibc fans usually compile everything locally, and only need
side-by-side at the moment of rollover, I'd add a single "LIB_ELF_OLD_UC"
flags, and provide a utility to mark every binary on a system as "OLD" to
ld.so and ldconfig.  Rather than an endless LIB_ELF_LIBC0_1,
LIB_ELF_LIBC0_2, ... until the type field overflows....  This would
suffice so long as every old-ABI program gets recompiled before the next
ABI break)

It occurs to me that what you might want is not side-by-side, but
self-identification of executables.  So that if you run into some old
forgotten binaries, you can guess what version of uClibc they were meant
for.  But that can be dealt with in other ways, such as the "ABI tag" note
that glibc uses.

---- Michael Deutschmann <michael at talamasca.ocis.net>