This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Fixing mkinstalldirs to avoid non-thread-safe mkdir -p
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- To: Russ Allbery <rra at stanford dot edu>
- Cc: Nathanael Nerode <neroden at twcny dot rr dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 09 Feb 2004 05:56:09 +0100
- Subject: Re: [RFA] Fixing mkinstalldirs to avoid non-thread-safe mkdir -p
- References: <20040208080807.GA29635@twcny.rr.com> <87oes96hhy.fsf@windlord.stanford.edu>
On Sun, 2004-02-08 at 10:35, Russ Allbery wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
>
> > I'd like to propose this patch for GCC 3.4; it fixes a stupid regression
> > on Solaris 2.7 / Solaris 8, where mkdir -p is not thread-safe.
>
> I'm not sure thread-safe is the word that you want here, since mkdir
> itself is not threaded. When that phrase was first used in this thread,
> my immediate reaction is "why would that matter?"
>
> I don't know if there's another good word that means "not safe against
> concurrent invocation."
> > +# Solaris 8's mkdir -p isn't thread-safe! If you mkdir -p a/b and
> > +# mkdir -p a/c at the same time, both will detect that a is missing,
AFAICT, this issue exists on many platforms besides Solaris, including
Linux (I have encountered this issue on FC1 with other packages,
myself).
> > +# one will create a, then the other will try to create a and die with
> > +# a "File exists" error. So we have to disable this code on Solaris 8.
To me this sounds like using dependencies on directories in Makefiles.
This is known to be troublesome and non-portable.
A general work-around to this issue is using dirstamp files and
dependencies on them. automake-1.8.x applies this approach. So you might
want to search the automake and automake-patches list for corresponding
discussions.
Ralf