Hi Chen, You are right, simply renaming 'SDK_NAME' solves the issue.
Thanks, Martin ________________________________________ From: ChenQi <[email protected]> Sent: Wednesday, August 29, 2018 3:36:41 AM To: Martin Siegumfeldt; [email protected] Subject: Re: [yocto] Sequential generation of eSDK from with the same workspace fails for similar machines The problem is about two machines having the same TUNE_PKGARCH, and could be solved by setting TOOLCHAIN_OUTPUTNAME in your distro conf file to include MACHINE information. But I'm not sure if this is a bug and should be fixed. Let's wait for more opinions. Best Regards, Chen Qi On 08/28/2018 04:44 PM, Martin Siegumfeldt wrote: > Hi, > > I am subsequently trying to render eSDKs for two different machines from > within the same workspace. > > The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake > core-image-minimal -c populate_sdk_ext' whereas the second > (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -c populate_sdk_ext) > fails providing: > > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: The recipe > core-image-minimal is trying to install files into a shared area when those > files already exist. Those files and their manifest location are: > > /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.testdata.json > (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) > > /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.sh > (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) > Please verify which recipe should provide the above files. > > The build has stopped, as continuing in this scenario WILL break things - if > not now, possibly in the future (we've seen builds fail several months > later). If the system knew how to recover from this automatically it would, > however there are several different scenarios which can result in this and we > don't know which one this is. It may be you have switched providers of > something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in > that case you need to execute the clean task for both recipes and it will > resolve this error. It may be you changed DISTRO_FEATURES from systemd to > udev or vice versa. Cleaning those recipes should again resolve this error, > however switching DISTRO_FEATURES on an existing build directory is not > supported - you should really clean out tmp and rebuild (reusing sstate > should be safe). It could be the overlapping files detected are harmless in > which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It > could also be yo ur > build is including two different conflicting versions of things (e.g. > bluez 4 and bluez 5 and the correct solution for that would be to resolve the > conflict. If in doubt, please ask on the mailing list, sharing the error and > filelist above. > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: If the above message is > too much, the simpler version is you're advised to wipe out tmp and rebuild > (reusing sstate is fine). That will likely fix things in most (but not all) > cases. > ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: > sstate_task_postfunc > ERROR: Logfile of failure stored in: > /home/martin/work/z7000-distro/build/tmp/work/zcu104_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.14111 > ERROR: Task > (/home/martin/work/z7000-distro/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) > failed with exit code '1' > > > Since the machines are of the same CPU architecture and and the image being > the same, the previously built artifacts are about to be overwritten. AFAICS > images are neatly populated in subdirectories according to the machine name, > however since the SDKs are not populated according to the machine the above > issue is encountered. > > Is this not a supported use case, or am I missing a configuration? > > Thanks, > Martin -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
