If I add the following to local.conf to enable a multilib that uses uclibc instead of glibc: ---------- snip ----------- require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" baselib_virtclass-multilib-lib32 = "lib32" LIBCEXTENSION_virtclass-multilib-lib32 = "-uclibc" LIBCOVERRIDE_virtclass-multilib-lib32 = ":libc-uclibc" PREFERRED_PROVIDER_virtual/lib32-libc = "uclibc" PREFERRED_PROVIDER_virtual/lib32-libiconv = "libiconv" PREFERRED_PROVIDER_virtual/lib32-libintl = "gettext" USE_NLS_virtclass-multilib-lib32 = "no" CXXFLAGS_append_virtclass-multilib-lib32 = " -fvisibility-inlines-hidden" IMAGE_LINGUAS_virtclass-multilib-lib32 = "" LIBC_DEPENDENCIES_virtclass-multilib-lib32 = "uclibc uclibc-dbg uclibc-dev uclibc-thread-db" PTEST_ENABLED_virtclass-multilib-lib32 = "" ---------- snip ----------- With dizzy/fido you get the following error building any image: ---------- snip ----------- NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'lib32-glibc' ERROR: lib32-glibc was skipped: incompatible with target linux-uclibc ERROR: Required build target 'core-image-sato' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-sato', 'lib32-glibc'] ---------- snip ----------- If I disable the SkipPackage raising within the glibc recipe and use bitbake -g -DDD it appears that the PREFERRED_PROVIDER_virtual/lib32-libc is being completely ignored - it suggests setting it even though it's already set: ---------- snip ----------- DEBUG: providers for virtual/lib32-libc are: ['lib32-glibc', 'lib32-uclibc'] DEBUG: selecting virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/glibc/glibc_2.21.bb as PREFERRED_VERSION 2.21 of package lib32-glibc (for item virtual/lib32-libc) DEBUG: selecting virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/uclibc/uclibc_git.bb as PREFERRED_VERSION 0.9.33+git% of package lib32-uclibc (for item virtual/lib32-libc) DEBUG: sorted providers for virtual/lib32-libc are: ['virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/glibc/glibc_2.21.bb', 'virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/uclibc/uclibc_git.bb'] NOTE: multiple providers are available for virtual/lib32-libc (lib32-glibc, lib32-uclibc) NOTE: consider defining a PREFERRED_PROVIDER entry to match virtual/lib32-libc DEBUG: adding virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/glibc/glibc_2.21.bb to satisfy virtual/lib32-libc DEBUG: adding virtual:multilib:lib32:/home/paul/poky/poky/meta/recipes-core/uclibc/uclibc_git.bb to satisfy virtual/lib32-libc ---------- snip -----------
First observation is that if you comment out the "raise bb.parse.SkipPackage" anonymous python functions in the glibc recipe, the build at least doesn't abort. There are then PREFERRED_PROVIDER warnings. I think there is something odd going on with the multilib selection and BBCLASSEXTEND.
I've debugged this. I thought some background on how may be useful. Commenting out the SkipParse messages meant "bitbake core-image-minimal -g" could run. If you then grep task-depends.dot, you find: "core-image-minimal.do_configure" -> "lib32-ncurses.do_populate_sysroot" "core-image-minimal.do_configure" -> "lib32-glibc.do_populate_sysroot" which is a smoking gun. The question then becomes why is an image do_configure depending on those two things. This comes from TOOLCHAIN_NEED_CONFIGSITE_CACHE in toolchain-scripts. Unfortunately the value is hard to override however if you patch the class: diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass index 0e849e4..8809ec2 100644 --- a/meta/classes/toolchain-scripts.bbclass +++ b/meta/classes/toolchain-scripts.bbclass @@ -98,7 +98,7 @@ EOF #we get the cached site config in the runtime TOOLCHAIN_CONFIGSITE_NOCACHE = "${@siteinfo_get_files(d, True)}" TOOLCHAIN_CONFIGSITE_SYSROOTCACHE = "${STAGING_DIR}/${MLPREFIX}${MACHINE}/${target_datadir}/${TARGET_SYS}_config_site.d" -TOOLCHAIN_NEED_CONFIGSITE_CACHE = "${TCLIBC} ncurses" +TOOLCHAIN_NEED_CONFIGSITE_CACHE ??= "${TCLIBC} ncurses" #This function create a site config file toolchain_create_sdk_siteconfig () { then set TOOLCHAIN_NEED_CONFIGSITE_CACHE = "" in local.conf, the build will proceed correctly (even once the SkipParse is reinstated, that isn't the issue, just helps with debugging). How we fix TOOLCHAIN_NEED_CONFIGSITE_CACHE properly needs more thought. The issue is the TCLIBC is not being used correctly in the multilib context.
To give a status update, the aforementioned workaround has been merged: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=59c09e3755f3ceabc7fc31af9346da3524e365e2 Ideally though what we really still need is a better way of handling this so you don't need to set TOOLCHAIN_NEED_CONFIGSITE_CACHE. I've also filed bug #7623 to avoid having to disable the SkipPackage/SkipRecipe when debugging situations like this in future.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6cfed59323ce51909bbf2c8efbceb50e67835eb7
verified on commit: 71b0568fa43285f0946fae93fb43cea5f3bbecec no build errors found on "bitbake core-image-minimal", after enabling multilib that uses uclibc