[OE-core] State of bitbake world, Failed tasks 2017-03-27

Patrick Ohly patrick.ohly at intel.com
Wed Mar 29 09:38:38 UTC 2017


On Wed, 2017-03-29 at 11:14 +0200, Martin Jansa wrote:
> On Wed, Mar 29, 2017 at 10:35:23AM +0200, Patrick Ohly wrote:
> > On Wed, 2017-03-29 at 09:23 +0200, Martin Jansa wrote:
> > > INFO: jenkins-job.sh-1.8.19 Complete log available at http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170328_014155.log
> > 
> > That used OE-core 552bd78, if I read this right:
> > 
> >         == Tested changes (not included in master yet) - openembedded-core ==
> >         latest upstream commit: 
> >         552bd78 wic: use kernel_dir to find systemd-efi bootloader
> > 
> > >     * openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb:do_compile
> > 
> > http://errors.yoctoproject.org/Errors/Details/135202/
> > 
> > "gcc-ar: not found" - that should have been fixed by OE-core 23a12d87a6
> > "fix toolchain selection", which is included in OE-core 552bd78 and thus
> > should have been included in the build.
> > 
> > However, the error above was "Submitted on: 11/03/17 10:13", which was a
> > while ago and in particular before that fix.
> > 
> > Did ovmf really fail in the latest world build?
> 
> The report shows:
> http://errors.yoctoproject.org/Errors/Build/34933/
> which leads to:
> 
> http://errors.yoctoproject.org/Errors/Details/138261/
> Submitted on: 27/03/17 05:31

Got it. I followed the wrong link at some point.

> So yes it failed again, but this time with different error:
> TOPDIR/tmp-glibc/work/i586-oe-linux/ovmf/git-r0/recipe-sysroot-native/usr/bin/i586-oe-linux/../../libexec/i586-oe-linux/gcc/i586-oe-linux/6.3.0/ld:
> internal error in do_layout, at ../../gold/object.cc:1821

Hmm, internal error in gold. Not sure what to do about that :-/

Can individual recipes choose to be built using the normal ld?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






More information about the Openembedded-core mailing list