Updating uClibc's ELFs when binary compatibility breaks?

[Mike Frysinger]

On Saturday 09 May 2009 16:15:33 Kyle Sallee wrote:
> Looking at the uClibc ELF libraries created by buildroot-2009.02
> I see
> libc.so.0 -> libuClibc-0.9.30.so
> However, what if the soname were instead
> libc.so.0.9.30

this is exactly the last thing we want to do

> That way libc.so.0 can be abandoned and no longer used,
> while software compiled and linked with the older uClibc
> would dynamically link with libc.so.0.9.30
> while software compiled with the newer uClibc
> would dynamically link with libc.so.0.9.30.1
> Are so names more limited than that?

the problem is that the ldso is hardcoded as the PT_INTERP and the ldso is 
strictly tied to the other C libraries

> Also changing the soname for the dynamic linker from
> ld-uClibc.so.0
> to something else
> would require a tiny modification to gcc or gcc's spec file.
> But would it be necessary?
> Will ld-uClibc break binary compatibility?

"tiny modification" here translates into unnecessary / unmanageable work

> Overall my request is a bit complicated.
> However, it would be nice if the soname for uClibc's ELF libraries
> changed whenever binary compatibility breaks.

you say "binary compatibility breaks" but never once stated what and how

> Assuming uClibc does not change sonames,
> is there an easy method for adding
> a RPATH to uClibc that is inherited
> by any ELF that links with a uClibc ELF?

that is not how RPATHs work.  normally it applies only to the current ELF 
whose the DT_RPATH tags are compiled into.

> That way I could install uClibc's ELFs in a place such as
> /lib/uClibc/$VERSION/

the uClibc configuration allows for you to set some default "system" paths so 
you could do this

> Please, if there are some nice suggestions for smooth updating
> of installed uClibc's ELF libraries please send them my way.
> If uClibc's sonames changed when binary compatibility breaks

we typically provide for transitional compatibility across a few releases.  
that way you can upgrade to a newer version, rebuild all relevant objects, and 
then disable the compat and/or upgrade to the next version.

we dont break binary compatibility for fun but when it does break, we document 
what/why/how/etc...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090509/6dac0904/attachment.pgp>