On Sunday 02 May 2010 14:23:29 Timo Teräs wrote: > 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.
Isn't this what static linking is for? > 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. Or the package manager would have to be statically linked? (Yeah there's some implementation details making sure the stuff it calls during its operation still works, too, changing the $PATH to point to a static busybox covers a multitude of sins...) > 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. Or you could just statically link the package manager? > 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). *shrug* Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
