[OE-core] [PATCH] target-sdk-provides-dummy: set nostamp for do_package

Richard Purdie richard.purdie at linuxfoundation.org
Mon Nov 4 13:44:38 UTC 2019


On Mon, 2019-11-04 at 14:51 +0800, changqing.li at windriver.com wrote:
> From: Changqing Li <changqing.li at windriver.com>
> 
> 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






More information about the Openembedded-core mailing list