On Mon, 2019-11-04 at 14:51 +0800, [email protected] wrote: > From: Changqing Li <[email protected]> > > It exists a situation that there is a common config file includes > multilib.conf but variable MULTILIBS is not set by default: > > require conf/multilib.conf > MULTILIBS ?= "" > > When build target-sdk-provides-dummy in the same build project with > following steps, it fails. > > 1 $ echo 'MACHINE = "qemux86"' >>conf/local.conf > $ bitbake target-sdk-provides-dummy > 2 $ cat <<EOF >>conf/local.conf > MACHINE = "qemux86-64" > MULTILIBS = "multilib:lib32" > DEFAULTTUNE_virtclass-multilib-lib32 = "i586" > EOF > $ bitbake target-sdk-provides-dummy > $ bitbake lib32-target-sdk-provides-dummy > > It fails to build lib32-target-sdk-provides-dummy with error > messages: > > > ERROR: target-sdk-provides-dummy-1.0-r0 do_packagedata: The recipe > > target-sdk-provides-dummy > > is trying to install files into a shared area when those files > > already exist. Those files > > and their manifest location are: > > .../tmp/pkgdata/qemux86-64/lib32-target-sdk-provides-dummy > > (matched in manifest-qemux86_64-lib32-target-sdk-provides- > > dummy.packagedata) > > .../tmp/pkgdata/qemux86-64/runtime/lib32-target-sdk-provides- > > dummy > > (matched in manifest-qemux86_64-lib32-target-sdk-provides- > > dummy.packagedata) > > ... snip ... > > Please verify which recipe should provide the above files. > > Because target-sdk-provides-dummy is a virtual package, its sstate > caches are same for both qemux86 and qemux86_64. So when build > target-sdk-provides-dummy for qemux86_64, it re-uses the sstate cache > from qemux86 and then create file lib32-target-sdk-provides-dummy > under > ${PKGDATA_DIR} which should not and it conflicts with > lib32-target-sdk-provides-dummy too. > > So make do_package always be executed to fix the issue. Because it is > a > dummy package, it won't cost too much build time.
Shouldn't we ensure that the packagedata has different sstate signatures? Maybe do_packagedata needs a dependency on PN through vardeps? Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
