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 <jpewhac...@gmail.com> wrote:
> On Wed, Jul 1, 2020 at 9:47 AM MikeB <mabnh...@gmail.com> 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 <mabnh...@gmail.com> 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 <st...@sakoman.com>
> wrote:
> >>>
> >>> On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
> >>> lists.yoctoproject.org <steve=sakoman....@lists.yoctoproject.org>
> >>> wrote:
> >>> >
> >>> > On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <jpewhac...@gmail.com>
> wrote:
> >>> > >
> >>> > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhac...@gmail.com>
> wrote:
> >>> > > >
> >>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnh...@gmail.com>
> 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
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49831): https://lists.yoctoproject.org/g/yocto/message/49831
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
