[uClibc]Preparing for another release....

David Schleef ds at schleef.org
Tue Aug 27 02:28:12 UTC 2002


On Mon, Aug 26, 2002 at 07:45:48PM -0600, Erik Andersen wrote:
> Yes, changing the config can cause binary incompatibilities.
> There really isn't too much of a standard, since (thus far)
> uClibc has not ever been geared towards maintaining binary
> compatibility.  We are probably close now to the point where such
> a thing may become worthwhile.  But I don't want to be boxed into
> that quite yet.  

That's why I'm suggesting it now. =)  I think the ability to (and
even, the concept of) throw away the ABI in the interest of
optimizing for size is one of the great benefits of uClibc.

What I'd like to see is some generic configuration defined as
the standard ABI, and given a soname such as 'libuclibc.so.1-std'.
Modified configurations (that change the ABI) get different
sonames, either one for all configurations ('libuclibc.so.1-nonstd'),
one for each possible config (sonames withheld), or one for some
of the major configurations ('libuclibc.so.1-linux22' or
'libuclibc.so.1-nolf' (large file)).

By the way, I don't think _missing_ symbols are a problem --
the symbols are _missing_, of course it's going to break.
Presumably, most people these days are rebuilding libraries
with mklibs anyway.

> What is their soname, and what do you suggest?

glibc uses "libc.so.0"



dave...




More information about the uClibc mailing list