Rob Landley wrote:
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...
No, the idea is not to have two versions installed all the time. The idea
is to allow the coexistance temporarily while package manager is upgrading
system. If we targeted flashable upgrade, then this would not be needed as
everything would be updated in one go.
If stuff is upgraded package at time, where libc is in one packages, and
e.g. busybox in separate package, we do need temporarily to have two
libc's if the ABI is incompatible. Otherwise the package manager would
have to have lots of extra kludge for libc upgrade. After full dist upgrade
the old libc should be gone, and new in place. But temporarily it needs to
work so e.g. perl/bb/shells/whatever works while their libc is mismatching.
And yes, it's not full solution. Deep library wise dependencies can be
temporarily broken. And yes, we do need stable API for uclibc at some point.
But since we don't have that yet, the temporary install of two libraries
during upgrade is the best option.
As conclusion was previously, it does not make sense to set ABI_VERSION
due to gcc dynamic-linker issues. But it'll help distro which tries to
keep compatibility on packages level (sets the dependencies right and
wants to perform clean upgrades).
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
