On Sun, 2 May 2010, Timo wrote: > And yes, it's not full solution. Deep library wise dependencies can be > temporarily broken.
The problem is that just one level of shared library other than the C library, is sufficient to break side-by-side execution based *only* on C library soname changes. That means using, for example, bash linked against libncurses, is enough to cause trouble. > And yes, we do need stable API for uclibc at some point. No we don't. When it comes to C library design, pick any two: 1. Long term ABI compatibility 2. Conformance to standards, which change from time to time 3. Avoidance of bloat libc.so.4 and libc.so.5 chose #1 and #3. Glibc chose #1 and #2, via linker magic that wasn't available for the previous libcs. uClibc is for those who want #2 and #3. (Or want to exclude features from the "standard" build, forcing #1 to be abandoned.) Don't get me wrong; official side-by-side support would indeed be useful. But just changing the soname *will not give you that*. ---- Michael Deutschmann <mich...@talamasca.ocis.net> _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
