Michael Deutschmann wrote:
On Tue, 20 Apr 2010, Natanael Copa wrote:
Since sublevel releases are not ABI compatible we need to adjust
the soname to include the sublevel version.
I see two reasons that this would be pointless.
First, you'd need more than a more precise statement of the uClibc source
version, because with uClibc, a single version of the source can produce
many different ABI-incompatible libc.so.0 files.
Yes, this does not help on building universal side-by-side thing.
But within one distribution you generally want to keep the ABI compatible.
This really is configuration management issue, and doable inside a single
distribution.
Second, sonames don't really help with the C library, because every other
shared library on a system is linked to the C library. The differences in
the C library often distort the ABI of these other libraries. It's very
complicated to keep appropriate versions side-by-side because the soname
of the other shared libraries does not change.
In the case where the C library change doesn't outright break the other
shared libraries, changing the soname makes it worse because an
application can end up loading two different C libraries at once -- one
through it's own DT_NEEDED, and one through the DT_NEEDED on another
shared library.
Again. This is configuration management issue. The distribution build system
and package manager need to take special precaution here to not create
binary packages ultimately depending on two different ABI versions of same
package.
The patch is still useful, as it makes ABI_VERSION configurable so each
builder can define their ABI_VERSION something that makes sense to them.
This is not a universal solution for all, but a step to right direction
and helps a lot of distribution maintainer who would like to have a clean
upgrade path. So IMHO the soname makes sense.
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
