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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc