[poky] poky-image-sato-sdk failed at do_rootfs

[Tian, Kevin]

> From: Richard Purdie
> Sent: Sunday, January 30, 2011 6:13 PM
> 
> On Sat, 2011-01-29 at 17:33 -0800, Zhang, Jessica wrote:
> > My poky-image-sato-sdk against the latest master is consistently
> > failed at last step of do_rootfs, here's the error:
> >
> >  Processing task-poky-qt-demos...
> > | error: Failed dependencies:
> > |  eglibc >= 2.12 is needed by libstdc++6-4.5.1-r2.armv5te
> > |  eglibc >= 2.12 is needed by libgcc1-4.5.1-r0.armv5te
> > | Function 'do_rootfs' failed
> > (see
> /home/jzhang/master-arm-build/tmp/work/qemuarm-poky-linux-gnueabi/poky-
> image-sato-sdk-1.0-r0/temp/log.do_rootfs.6142 for further information)
> > | ERROR: Function 'do_rootfs' failed
> > (see
> /home/jzhang/master-arm-build/tmp/work/qemuarm-poky-linux-gnueabi/poky-
> image-sato-sdk-1.0-r0/temp/log.do_rootfs.6142 for further information)
> >
> > Has anybody run into same issue or any idea?
> 
> This looks like a race issue we once had. Grepping the gcc include files
> revealed:
> 
> gcc-configure-cross.inc:do_package_write_ipk[depends] +=
> "virtual/libc:do_package"
> 
> which was added to address this problem. Of course now, libgcc and
> libstdc++ are built by libgcc and gcc-runtime so I think the correct
> approach is to make both of these dependent on the libc packaging to
> finish.

Curious how that race condition doesn't cause issue in the 1st place when libgcc
and gcc-runtime are compiled, while only occurs in final rootfs stage...

BTW, today I took a brief look in Lianhao's cube. His phenomenon is even more
complex I think because when above error of do_rootfs is thrown out there're
still 6-7 ongoing tasks which are waited to complete.

> 
> This also shouldn't be ipk specific, in the modern world we can depend
> on do_package_write.
> 
> The problem is that "eglibc" gets renamed to libc at package time. If
> the package step hasn't run, the renaming isn't applied to the
> dependencies that libgcc and libstdc++ have on libc and you see this
> error. If you rebuild those packages, the image should work. Since its a
> race, some builds will work, some won't. Using rm_work will make this
> bug more likely to appear at a guess.
> 

Since Lianhao also observed this issue, we'll take a look at this issue tomorrow.

Thanks
Kevins