This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/11932] [3.4/3.5 regression] Parallel bootstrap failure with sparc libiberty multilib
- From: "ian at wasabisystems dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Jan 2004 06:22:38 -0000
- Subject: [Bug bootstrap/11932] [3.4/3.5 regression] Parallel bootstrap failure with sparc libiberty multilib
- References: <20030815185146.11932.lucier@math.purdue.edu>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From ian at wasabisystems dot com 2004-01-27 06:22 -------
Subject: Re: [3.4/3.5 regression] Parallel bootstrap failure with sparc libiberty multilib
"neroden at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> ------- Additional Comments From neroden at gcc dot gnu dot org 2004-01-27 06:03 -------
> Fair warning: I'm completely at a loss as to what's going on here, and this
> isn't going to get solved until I can diagnose it! If anyone can help by
> figuring out why mkdir -p is failing, *please* tell me.
It seems possible that the Solaris mkdir is not robust in the face of
a directory being created after mkdir confirmed that the directory did
not exist. That would at least explain the ``File exists'' error.
The obvious workaround would be to create $(TARGET_SUBDIR) before
calling mkinstalldirs on $(TARGET_SUBDIR)/DIR. That is what used to
happen--$(TARGET_SUBDIR) used to be created by configure. Why don't
you try that and see if it fixes the problem. Alternatively, try
commenting out the code in mkinstalldirs which execs mkdir -p, and see
if that fixes the problem--the mkinstalldirs shell script appears to
be robust.
Ian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11932