[PATCH] nptl: proper soname handling

Rob Landley rob at landley.net
Sun May 2 00:48:51 UTC 2010


On Friday 23 April 2010 10:08:42 Timo Teräs wrote:
> Austin Foxley wrote:
> > On 04/23/2010 07:18 AM, Timo Teräs wrote:
> >> Austin Foxley wrote:
> >>> On 04/20/2010 07:49 AM, Natanael Copa wrote:
> >>>> Since sublevel releases are not ABI compatible we need to adjust
> >>>> the soname to include the sublevel version.
> >>>>
> >>>> This makes it possible to install ABI incompatible versions of the
> >>>> library side by side so clean upgrades are possible.
> >>>
> >>> Applied, minus the mistaken LDFLAGS hunk
> >>
> >> It might be useful to do:
> >>
> >> -ABI_VERSION   := $(VERSION)
> >> +ABI_VERSION   := $(MAJOR_VERSION)
> >>
> >> Since it seems that ld.so soname is hardcoded in GCC. If you want to
> >> use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
> >> need to update GCC default configration, create alternate specfile
> >> overriding the hardcoded -dynamic-linker, or pass-in
> >> -Wl,-dynamic-linker,...
> >> when compiling.
> >
> > Hmm, I didn't realize GCC hardcoded that. I'll push a fix.
>
> Me neither. Actually the dynamic section is generated properly. It's
> the .interp section that goes wrong. And I didn't notice that until
> trying to run things side-by-side where ld-uClibc.so.0 and
> ld-uClibc.so.0.9.32 did not refer to same file.

So let me get this straight:

You're saying you want to support having two installations of uClibc the same 
system.  Starting from separate dynamic linkers, and going through segregated 
library search paths.  Because nothing says "lightweight and embedded" like 
installing two or three complete copies of your entire library search path 
side by side.

What are you going to do about things like X11's libraries?  Build that twice 
too?  Along with zlib and openssl and whatever else the system needs?  
(Because it seems like you'd have to; how is shared library code calling into 
libc any different than an executable calling into libc?  Either you have a 
stable ABI with glue code and a collection of version-annotated obsolete 
symbols to bind against, or you don't.  When sizeof(sigset_t) changes, or you 
flip a config switch like UCLIBC_HAS_COMPAT_RES_STATE or 
UCLIBC_HAS_TM_EXTENSIONS or ipv6 or internationalization support...  Well 
libSDL.so depends on libc (and librt, libpthread, libm...) just as much as 
/bin/ls does.

It sonds like you're inviting users to experience the joy of _subtle_ bugs 
caused by library version skew.  (And, of course, to post them to this mailing 
list...)

Why are we opening this can of worms again?  I missed a curve...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the uClibc mailing list