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

uClibc status


I'm still in the middle of packaging the 0.9.30rc3 candidate. There will be
a lot more binary packages than before:

 - On all architectures, there is a single package "libuclibc-dev" that
   provides whatever is necessary to build software against uclibc

For the "debian" vendor:

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

 - 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.

 - Likewise, 32-bit architectures with a meaningfule -m64 variant (i386,
   powerpc, sparc, mips) get "uclibc64-0.9.30rc3" and "lib64uclibc-dev"

 - All other ABI-changing variants are thrown together in a big package
   "uclibc0.9.30rc3-multilib". This package exists only on architectures
   where there actually are such variants, of course.

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

I'm unsure whether to build -pic and -dbg packages right now, and if so,
whether to build them for the 32, 64 and multilib packages as well. The
other thing I'm still undecided on is the "other variant" builds for the
"emdebian" vendor: I can see an use case for a separate
"libc0.9.30rc3uc-thumb" package, but I don't see how I could generate the
package names in a sane way (also "libc0.9.30rc3uc-big-endian" makes no
sense to have on a LE system, only when building software against it), so
I'm thinking about handling the options where it makes sense to have fine
grained runtime packages in the same "special" way that I handle 32/64, and
just lump the rest together into a huge "multilib" package or omit them

Questions, comments?


Attachment: signature.asc
Description: Digital signature

Reply to: