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 <[email protected]> _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
