Re: Dunfell 3.1.1 gcc-sanitizers build failure


MikeB
 

Yes, I am using the archiver.bbclass.  However, I'm using the one in poky/meta.  I applied your patch (manually) to that one.

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index a8d3afcbe9..bf275f4543 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -583,8 +583,8 @@ do_deploy_archives[sstate-outputdirs] = "${DEPLOY_DIR_SRC}"
 addtask do_deploy_archives_setscene
 
 addtask do_ar_original after do_unpack
-addtask do_unpack_and_patch after do_patch
-addtask do_ar_patched after do_unpack_and_patch before do_preconfigure do_configure
+addtask do_unpack_and_patch after do_patch do_preconfigure
+addtask do_ar_patched after do_unpack_and_patch before do_configure
 addtask do_ar_configured after do_unpack_and_patch
 addtask do_ar_mirror after do_fetch
 addtask do_dumpdata

I should also point out that the failure is not limited to gcc-sanitizers.  On different architectures, the  same failure has occurred in gcc-cross-canadian_9.3.bb:do_configure and gcc-crosssdk_9.3.bb:do_configure.  So there are multiple recipes that reference work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h but it is missing.

On all architectures (that I use), executing a 'bitbake -c cleanall gcc-source-9.3.0' and rebuilding works around the issue and the build succeeds.

Please note that it is not the image build that is failing; it is the populate_sdk command that fails.

Regards, Mike


On Wed, Jul 1, 2020 at 10:52 AM Joshua Watt <jpewhacker@...> wrote:
On Wed, Jul 1, 2020 at 9:47 AM MikeB <mabnhdev@...> wrote:
>
> The rumors of my success were exaggerated.  If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post.  If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.

Ok. Are you using archiver.bbclass?

>
> Mike
>
> On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@...> wrote:
>>
>> The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.
>>
>> Thank you all for the help!
>>
>> On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
>>>
>>> On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
>>> lists.yoctoproject.org <steve=sakoman.com@...>
>>> wrote:
>>> >
>>> > On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
>>> > >
>>> > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
>>> > > >
>>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
>>> > > > >
>>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
>>> > > > >
>>> > > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
>>> > > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
>>> > > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
>>> > > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > >
>>> > > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
>>> > > >
>>> > > > I've encountered a similar error just today when switching SDKMACHINE.
>>> > > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
>>> > > > just recently fixed a bug in archive.bbclass
>>> > > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
>>> > > > gcc-source raced with do_preconfigure and I'm wondering if it's
>>> > > > related
>>> > >
>>> > > I believe I have fixed this in
>>> > > https://lists.openembedded.org/g/openembedded-core/message/140161,
>>> > > please try it out to make sure it solves your issue as well.
>>> >
>>> > That patch came in after the 3.1.1 release, but it is present in the
>>> > dunfell branch so it will make it into 3.1.2
>>>
>>> Doh, I'm getting ahead of myself! I was thinking of another
>>> classes/archiver patch that Joshua sent :-)
>>>
>>> Steve

Join yocto@lists.yoctoproject.org to automatically receive all group messages.