Recipe which builds for ARCH '${TUNE_PKGARCH}' and 'all' fail

Recipe which builds for ARCH '${TUNE_PKGARCH}' and 'all' fail

[Max Krummenacher]

Hi

If a recipe builds a package for the default ARCH (I think this is
${TUNE_PKGARCH}) and one for ARCH 'all' then this fails when building
in the same directory a second time for a machine with different
${TUNE_PKGARCH}.
Observed with dizzy (armv7at2hf-vfp vs armv7at2hf-vfp-neon) and
master (MACHINE=qemux86-64 vs qemuarm)


ERROR: The recipe mixed-arch-test is trying to install files into a
shared area when those files already exist. Those files and their
manifest location are:
   /mnt/sdc2/oe-disk/oe-core_master/oe-core/build/tmp-glibc/deploy/ipk/all/mixed-arch-test-a_1.0-r0_all.ipk
 Matched in manifest-core2-64-mixed-arch-test.package_write_ipk


An example in the wild is meta-java/recipes-core/rhino/rhino_1.7r4.bb
which builds: rhino_1.7r4-r0_armv7at2hf-vfp.ipk and
librhino-java_1.7r4-r0_all.ipk.

See below for a simple test recipe which reproduces the error.


Is this intended behavior or an issue oe-core?


Simple workaround:
- don't build machines with different architectures in the same build
directory.

Workarounds at recipe level:
- build all packages for TUNE_PKGARCH, even if the nature of the package
would be 'all'.
- have two recipes, one providing packages to TUNE_PKGARCH, the other
one to 'all'.


Regards
Max


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
SUMMARY = "Test build of packages of different ARCHs"
DESCRIPTION = "This recipe builds a package with ARCH '${TUNE_PKGARCH}'
and one with 'all' " \
              "When building this in the same build directory for
MACHINES with different " \
              "TUNE_PKGARCH" do_package_write_ipk fails for the second
build "

#Successful build for armv7at2hf-vfp, second build for
armv7at2hf-vfp-neon
#ERROR: The recipe mixed-arch-test is trying to install files into a 
#   shared area when those files already exist.
#   Those files and their manifest location are:
#   /build/krm/oe-core_V2.4/build/out-glibc/deploy/ipk/all/mixed-arch-test-a_1.0-r0_all.ipk
#   Matched in manifest-armv7at2hf-vfp-mixed-arch-test.package_write_ipk

LICENSE = "MIT"
LIC_FILES_CHKSUM = \
"file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

DEPENDS = ""

SRC_URI = ""

PACKAGES = "${PN} ${PN}-a"

PACKAGE_ARCH_${PN}-a ="all"
FILES_${PN} = "${datadir}/file1.txt"
FILES_${PN}-a = "${datadir}/file2.txt"

do_compile() {
    touch file1.txt
    touch file2.txt
}

do_install() {
    install -d ${D}${datadir}
    install -m 0644 ${WORKDIR}/file1.txt ${D}${datadir}
    install -m 0644 ${WORKDIR}/file2.txt ${D}${datadir}
}

S = "${WORKDIR}"
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Re: Recipe which builds for ARCH '${TUNE_PKGARCH}' and 'all' fail

[Richard Purdie]

On Fri, 2015-02-13 at 13:44 +0100, Max Krummenacher wrote:
> Hi
> 
> If a recipe builds a package for the default ARCH (I think this is
> ${TUNE_PKGARCH}) and one for ARCH 'all' then this fails when building
> in the same directory a second time for a machine with different
> ${TUNE_PKGARCH}.
> Observed with dizzy (armv7at2hf-vfp vs armv7at2hf-vfp-neon) and
> master (MACHINE=qemux86-64 vs qemuarm)
> 
> 
> ERROR: The recipe mixed-arch-test is trying to install files into a
> shared area when those files already exist. Those files and their
> manifest location are:
>    /mnt/sdc2/oe-disk/oe-core_master/oe-core/build/tmp-glibc/deploy/ipk/all/mixed-arch-test-a_1.0-r0_all.ipk
>  Matched in manifest-core2-64-mixed-arch-test.package_write_ipk
> 
> 
> An example in the wild is meta-java/recipes-core/rhino/rhino_1.7r4.bb
> which builds: rhino_1.7r4-r0_armv7at2hf-vfp.ipk and
> librhino-java_1.7r4-r0_all.ipk.
> 
> See below for a simple test recipe which reproduces the error.
> 
> 
> Is this intended behavior or an issue oe-core?
> 
> 
> Simple workaround:
> - don't build machines with different architectures in the same build
> directory.
> 
> Workarounds at recipe level:
> - build all packages for TUNE_PKGARCH, even if the nature of the package
> would be 'all'.
> - have two recipes, one providing packages to TUNE_PKGARCH, the other
> one to 'all'.

The issue is that for true allarch packages you should be able to
inherit the allarch class. That does some magic which means it shouldn't
rebuild for each MACHINE.

Cheers,

Richard

Re: Recipe which builds for ARCH '${TUNE_PKGARCH}' and 'all' fail

[Max Krummenacher]

Hi


Am Freitag, den 13.02.2015, 14:51 +0000 schrieb Richard Purdie:
> On Fri, 2015-02-13 at 13:44 +0100, Max Krummenacher wrote:
> > Hi
> > 
> > If a recipe builds a package for the default ARCH (I think this is
> > ${TUNE_PKGARCH}) and one for ARCH 'all' then this fails when building
> > in the same directory a second time for a machine with different
> > ${TUNE_PKGARCH}.
> > Observed with dizzy (armv7at2hf-vfp vs armv7at2hf-vfp-neon) and
> > master (MACHINE=qemux86-64 vs qemuarm)
> > 
> > 
> > ERROR: The recipe mixed-arch-test is trying to install files into a
> > shared area when those files already exist. Those files and their
> > manifest location are:
> >    /mnt/sdc2/oe-disk/oe-core_master/oe-core/build/tmp-glibc/deploy/ipk/all/mixed-arch-test-a_1.0-r0_all.ipk
> >  Matched in manifest-core2-64-mixed-arch-test.package_write_ipk
> > 
> > 
> > An example in the wild is meta-java/recipes-core/rhino/rhino_1.7r4.bb
> > which builds: rhino_1.7r4-r0_armv7at2hf-vfp.ipk and
> > librhino-java_1.7r4-r0_all.ipk.
> > 
> > See below for a simple test recipe which reproduces the error.
> > 
> > 
> > Is this intended behavior or an issue oe-core?
> > 
> > 
> > Simple workaround:
> > - don't build machines with different architectures in the same build
> > directory.
> > 
> > Workarounds at recipe level:
> > - build all packages for TUNE_PKGARCH, even if the nature of the package
> > would be 'all'.
> > - have two recipes, one providing packages to TUNE_PKGARCH, the other
> > one to 'all'.
> 
> The issue is that for true allarch packages you should be able to
> inherit the allarch class. That does some magic which means it shouldn't
> rebuild for each MACHINE.
> 
> Cheers,
> 
> Richard
> 
Hi

Thank you Richard. Inheriting allarch indeed makes the error go away.
There is still the less important issue that the package in the earlier
TUNE_PKGARCH feed is deleted while the one in the latest is built.

However your comment also made me realize that at least for the rhino
recipe all packages can be put into the allarch group which makes the
whole a non issue.

Regards Max