[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uClibc status


> >  - On all architectures, the package "uclibc0.9.30rc3" contains all
> >    run-time libraries in a single package.

> Do we need the full version string within the package name? Is the ABI
> that unstable? Is it likely to stabilise? I don't fancy all those binary
> rebuilds. Or is that actually "uclibc_0.9.30rc3" or uclibc0? uclibc0.9
> might be OK.

Well, the ABI broke with minor uploads before. I could probably drop the
"rc3" bit (in fact I think that's a good idea) and just assume that
candidate versions will be ABI compatible with the release.

> >  - On 64-bit architectures that have a -m32 variant (amd64 only, I think),
> >    "uclibc32-0.9.30rc3" provides a 32-bit build, and "lib32uclibc-dev"
> >    provides the static libraries and .so symlink for that.

> That forces every reverse depends to update to the latest uclibc every
> time a new upload is made, it doesn't allow for migrations where
> lib32uclibc0.9-dev sits alongside lib32uclibc0.10-dev. glibc transitions
> are painful and protracted.

Both versions should be API compatible, so making versioned -dev packages
and integrating them into compilers would be a waste of effort, IMO.

The runtime libraries can be installed at the same time, and in general can
be used in the same process even if noone makes the assumption that
pointers received from a library may be freed directly using free(), so
transitions should be far easier than with glibc.

Transitioning glibc is harder than transitioning uclibc, because the glibc
does a few things that cease to work when two different copies of libc are
in the same address space, for example caching the current brk address.

With uClibc, we can just rebuild packages and mix different libc versions,
which will be slightly inefficient but should not break.

> > For the "emdebian" vendor:
> > 
> >  - On all architectures, "libc0.9.30rc3uc" provides libc, "libm0.9.30rc3uc"
> >    contains libm, and so on.
> >  - 32/64 bit variant builds are named "lib32c0.9.30rc3uc" and
> >    "lib64c0.9.30rc3uc", respectively
> libc0.9uc ? Is that ABI really going to change that much between rc3 and
> rc4 or between 0.9.30* and 0.9.31 ?

Dropping the "rc3" bit is fine.

The most interesting questions for me would be if the package split makes
sense, specifically the multilib bits for emdebian.


Reply to: