* race between aclocal and unstaging of .m4 files
@ 2012-10-29 14:42 Phil Blundell
2012-10-29 15:45 ` Richard Purdie
0 siblings, 1 reply; 2+ messages in thread
From: Phil Blundell @ 2012-10-29 14:42 UTC (permalink / raw)
To: openembedded-core
If do_configure() from one recipe runs in parallel with
sysroot_cleansstate() from another then aclocal may fail because it
doesn't react very well to .m4 files disappearing underneath it. This
manifests as slightly obscure failures such as:
| aclocal: error: aclocal: file '.../tmp-eglibc/sysroots/x86_64-linux/share/aclocal/alsa.m4' does not exist
where the .m4 file in question is not one that the recipe being built
would actually want to use. (The alsa.m4 error above actually occurred
during a build of attr.)
There seem to be two obvious ways of fixing this:
a) Add more locking so that these things can't happen in parallel
b) Patch aclocal to make this situation non-fatal
My inclination would be to do (b) since it's less intrusive. Any
objections or better suggestions?
p.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: race between aclocal and unstaging of .m4 files
2012-10-29 14:42 race between aclocal and unstaging of .m4 files Phil Blundell
@ 2012-10-29 15:45 ` Richard Purdie
0 siblings, 0 replies; 2+ messages in thread
From: Richard Purdie @ 2012-10-29 15:45 UTC (permalink / raw)
To: Phil Blundell; +Cc: openembedded-core
On Mon, 2012-10-29 at 14:42 +0000, Phil Blundell wrote:
> If do_configure() from one recipe runs in parallel with
> sysroot_cleansstate() from another then aclocal may fail because it
> doesn't react very well to .m4 files disappearing underneath it. This
> manifests as slightly obscure failures such as:
>
> | aclocal: error: aclocal: file '.../tmp-eglibc/sysroots/x86_64-linux/share/aclocal/alsa.m4' does not exist
>
> where the .m4 file in question is not one that the recipe being built
> would actually want to use. (The alsa.m4 error above actually occurred
> during a build of attr.)
>
> There seem to be two obvious ways of fixing this:
>
> a) Add more locking so that these things can't happen in parallel
>
> b) Patch aclocal to make this situation non-fatal
>
> My inclination would be to do (b) since it's less intrusive. Any
> objections or better suggestions?
Does current master not resolve this by creating a copy of the aclocal
directory using hardlinks and using that?
We've gone around in circles on this but I think its fixed once and for
all now.
Cheers,
Richard
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-10-29 15:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-29 14:42 race between aclocal and unstaging of .m4 files Phil Blundell
2012-10-29 15:45 ` Richard Purdie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox