On 16 May 2015 14:50, Peter Cordes wrote: > On Mon, May 11, 2015 at 10:05:28AM +0200, Karel Zak wrote: > > On Sun, May 10, 2015 at 01:38:08PM -0700, Isaac Dunham wrote: > > > On Tue, May 05, 2015 at 11:37:33AM +0100, Pádraig Brady wrote: > > > > On 04/05/15 04:51, Mike Frysinger wrote: > > > > > From: Mike Frysinger <vapier@xxxxxxxxxxxx> > > > > > > > > > > The symlink generation tries to write to the sys-utils/ subdir but does > > > > > not make sure that dir exists. This can sometimes lead to parallel build > > > > > failures when building out-of-tree > > > > > > > > > $(SETARCH_MAN_LINKS): > > > > > + $(AM_V_at) test -d $(dir $@) || mkdir -p $(dir $@) > > > > > $(AM_V_GEN)echo ".so man8/setarch.8" > $@ > > > > > > > > > > install-exec-hook-setarch: > > > > > > > > The `test -d ... ||` bit is racy and redundant I think > > > > > > Racy, yes, but no more so than "mkdir -p $DIR && install $FILE $DIR": > > > it's an inherent limitation of shell scripts. > > You mean racy as in multiple mkdir -p invocations could happen? A C > implementation could shorten the window for the race (because mkdir(2) > would directly follow stat(2), rather than delayed by > fork/exec/dynamic linker startup). Or handle EEXISTS specially and > test again for existance. You could do most of that in shell, but it > would make the code a mess. shortening the window isn't interesting. it's either race-free, or racy. the incident rate is irrelevant. -mike
Attachment:
signature.asc
Description: Digital signature
