Michael Deutschmann wrote:
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...
It means the system used to build all packages, is aware of the multiple
versions of libc it has had. It means it also makes sure the produced
binaries are only linked against one version of libc, and marks the
binary package dependencies so that the package manager can ensure that
all dependency libraries depend on same version of libc. Thus producing
a runnable application.
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.
You are right. It is the package managers responsibility to make sure
that there is no such conflicts.
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.
Why? This only needed for ldso cache. It would seem that these magics
are only used to see if the application is incorrectly linked against
different libc versions. It is probably mostly needed for the multilib
stuff where you have 32- and 64-bit libraries installed on same system.
I don't see any immediate problem with mapping libc.so.0* to LIB_ELF_LIBC0
because in addition to the flag field also the soname is compared. If
the package manager / build system ensures proper dependencies, the
soname is sufficient.
If ldso cache is turned off, this stuff is not even used at all.
But yes, the ld cache is not working exactly right now. It maps the
libc with long soname now to LIB_ELF. Everything will work, it just
will not emit the warning if linked against e.g. libc0 and libc6.
(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.
Well, ABI tag would be useful to double check that the build system
produced valid dependencies.
But changing soname in controlled manner should suffice.
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
