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

[Lu, Lianhao]

Lu, Lianhao wrote on 2011-01-30:
> Tian, Kevin wrote on 2011-01-30:
>>> 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/po
>>> k y - 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/po
>>> k y - 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.
>> 
> 
> Here is what I found using the master with the latest commit 
> ffd12fc476d6061ba1e019a1e789cf1a2d3c82e6.
> 
> 1. set PACKAGE_CLASSES to "package_rpm package_ipk" and target machine 
> to "qemumips" in conf/local.conf 2. bitbake poky-image-minimal from 
> scratch, then bitbake meta-toolchain incrementally. Both got built successfully.
> 3. set PACKAGE_CLASSES to "package_ipk package_rpm"
> 4. bitbake poky-image-minimal incrementally, and it succeeded.
> 5. bitbake meta-toolchain incrementally, it failed complaining about 
> unsatisfied dependencies to eglibc during opkg installation. See 
> attached file "log.do_populate_sdk" for details. This failure is then reproducible every time.
> 6. set PACKAGE_CLASSES back to "package_rpm package_ipk"
> 7. bitbake poky-image-minimal incrementally, it failed complaining 
> about unsatisfied dependencies to eglibc during rpm installation. See 
> attached file "log.do_rootfs" for details. This failure is then reproducible every time.
> 

Just as Richard said, we've confirmed that this issue was caused by a race problem. We saw this issue because the libgcc's do_package_write_xxx task got executed before the eglibc's do_pacakge task finished. This problem might be there for some time, but somehow it was not exposed until the recent commit of adding a non stamp task do_populate_lic.(see the email chain named after "summary about recent do_populate_sdk failures" for details).  We should add dependency so that the task package_write_xxx of libgcc and libstdc++ is dependent upon "virtual/libc:do_package". 

Is there any package other than libgcc and gcc-runtime have such race problem with libc? I think many packages are implicitly dependent on virtual/libc, how those packages do_package_write_xxx's dependency upon libc's do_package get assured?

Best Regards,
Lianhao