Re: work-shared not being correctly shared

[Saul Wold <sgw@linux.intel.com>]

On 09/24/2012 08:38 AM, Phil Blundell wrote:
> Since updating to the latest versions of bitbake and oe-core I'm
> experiencing some sort of conflict to do with the gcc sources in
> tmp/work-shared.
>
> What seems to be happening is that all the different recipes which share
> that source directory are using different stamp values for do_unpack.
> So, for example, I can do:
>
> $ bitbake -f -c unpack gcc-cross
> [ source unpacks ]
> $ ls -l tmp-eglibc/stamps/work-shared/gcc-4.7.2-r13.do_unpack*
> -rw-rw-r-- 1 pb pb 0 2012-09-24 15:37
> tmp-eglibc/stamps/work-shared/gcc-4.7.2-r13.do_unpack.ea6dd89ddae3dcc205848b41ce0251cd
> $ bitbake -f -c unpack gcc-cross
> [ nothing happens ]
> $ bitbake -f -c unpack gcc-cross
> [ still nothing happens ]
> $ bitbake -f -c unpack gcc-runtime
> [ source unpacks again ]
> $ ls -l tmp-eglibc/stamps/work-shared/gcc-4.7.2-r13.do_unpack*
> -rw-rw-r-- 1 pb pb 0 2012-09-24 15:42
> tmp-eglibc/stamps/work-shared/gcc-4.7.2-r13.do_unpack.e677db6d46e8c0c6109b02302aa477d0
> $ bitbake -f -c unpack gcc-runtime
> [ nothing happens ]
>
> Worse, if I set BB_NUMBER_THREADS to some high number, I seem to end up
> with multiple competing tasks all trying to unpack in parallel and the
> build never makes any real forward progress.
>
> Does anybody have any insight into what is going wrong here and how I
> should debug it?
>
Yes, I am seeing something similar with do_patch happening twice on the 
work-shared area, I talked with Richard a bit ago about it, and I am 
digging into the siginfo files, you can use bitbake-sigdiff to see what 
sigs are changed causing it unpack twice (or in my case patch twice).

Sau!

> thanks
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>