[OE-core] libc-common.bbclass and uclibc

Manuel Bessler manuel.bessler at gmail.com
Thu Jul 26 21:51:12 UTC 2012


I'm one of the (seemingly few) people using OE/Yocto on a uclibc platform.

Since I'm using a vendor-supplied toolchain, I had to make a few changes to
keep the build from trying to build uclibc despite it was being supplied via
the toolchain.

Comparing with the external-csl-toolchain recipe I found that it
"require"s eglibc-package.inc,
so I created a uclibc-package.inc. This fixed the above issue of
trying to build uclibc despite
it was already provided by the external toolchain.

In creating uclibc-package.inc I tried to follow closely how
eglibc-package.inc was implemented.

This has worked for me well until I started on the nativesdk with
external toolchain.
I noticed that my external-toolchain-xxx-cross-canadian_xxx.bb recipe
(which provides
uclibc*, binutils-cross-canadian, and gcc-cross-canadian) created
libc6, libc6-dev, and libc6-dbg
packages.

A quick search revealed meta/classes/libc-common.bbclass referencing libc6.
Function populate_packages_prepend() seems to just overwrite
PKG_${BPN} with libc6.

=========================================
python populate_packages_prepend () {
        if d.getVar('DEBIAN_NAMES', True):
                bpn = d.getVar('BPN', True)
                d.setVar('PKG_'+bpn, 'libc6')
...
=========================================

It does not seem to care about uclibc.
Maybe libc-common.bbclass is only for eglibc and might need a better name?
Since this is checking for "DEBIAN_NAMES" and I guess debian is not
uclibc based,
maybe this code is not really the issue...

Do I just need to create a uclibc-common.bbclass ?

Thanks,
Manuel




More information about the Openembedded-core mailing list