[poky] strange libgcc build failure in autobuilder

[Richard Purdie]

On Wed, 2011-01-19 at 10:42 +0000, Richard Purdie wrote:
> On Wed, 2011-01-19 at 10:13 +0000, Richard Purdie wrote:
> > On Wed, 2011-01-19 at 17:30 +0800, Cui, Dexuan wrote:
> > > I saw some libgcc(the new recipe I added days ago) failure that I can't reproduce locally.
> > > e.g.,  "qemux86 poky-image-sdk failed": http://autobuilder.pokylinux.org:8010/builders/nightly-internal-incremental/builds/16/steps/shell_5/logs/stdio
> > > 
> > > libgcc's do_package failed:
> > > ERROR: Error executing a python function in /builds2/pokybuilds/nightly-internal/build/meta/recipes-devtools/gcc/libgcc_4.5.1.bb:
> > > IOError: [Errno 2] No such file or directory: '/builds2/pokybuilds/nightly-internal/build/build/tmp/sysroots/i586-poky-linux/shlibs/cairo-perf-utils.list'
> > > 
> > > It's odd -- why cario-perf-utils.list is involved...
> > 
> > I've seen these errors before, they happen when one process
> > moves/deletes files in the shlibs directory while another is accessing
> > them.
> > 
> > In package_do_shlibs there is a lock to guard against it:
> > 
> > lf = bb.utils.lockfile(bb.data.expand("${PACKAGELOCK}", d))
> > 
> > so its as if something is failing with the lock, or accessing those
> > files without holding the lock...
> 
> In particular, this build was an incremental, and there were do_setscene
> calls which were uninstalling sstate data from the sysroots running at
> the same time libgcc was packaging.
> 
> There is a missing lock in setscene's uninstall which probably needs to
> take PACKAGELOCK. We could really do with some kind of read/write lock
> here since multiple readers are desirable and its a potential
> performance bottleneck...

These issues should all be fixed with these commits:

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=7857834691868b7f48f732ee78d8770f5473ff68
http://git.pokylinux.org/cgit.cgi/poky/commit/?id=ede381d56b180b384fdad98d445e5430819cfade
http://git.pokylinux.org/cgit.cgi/poky/commit/?id=542cebbc3282a0b3acb68a5ef0d8c2a61b0ecc38

Cheers,

Richard