[Bug other/42980] New: GCC parllel "make install" failures

["gary at intrepid dot com" <gcc-bugzilla at gcc dot gnu dot org>]

While testing some mods to the current pre-4.5 tree,
I ran into sporadic "make install" failures, when
running the make install as a parallel make (ie,
"make -jN" where N > 1).

The host is an x86_64 with 4 CPU cores, being built in the default
multi-lib mode.  The failures are sporadic, occurring
in only about 2% of the cases.

Here is an example of the failures:

mv: cannot stat `rls/usr/local/lib/../lib64/./libiberty.an': No such file
or directory
/usr/bin/install: cannot change permissions of
`rls/usr/local/lib/../lib64/./libiberty.an': No such file or directory
/usr/bin/install: cannot create regular file
`rls/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include/ssp/ssp.h':
File exists

Looking at libssp/Makefile.am, there is this definition:
nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h ssp/unistd.h

The failure above, I think may be the result of make install running
in both the 64-bit and 32-bit libssp build directories at the
ame time.  The install for the nobase_libsubinclude_HEADERS
target is run twice, and apparently in parallel, which seems
to lead to a race condition.

The libiberty failure is unrelated to the use of automake,
(because it isn't used).  I didn't research the cause of
that failure - it was the most frequently occurring failure, fyi.

Several libraries use automake and the libsubinclude_HEADERS
header definition: libgomp, libmudflap, and libssp which
would seem to make them susceptible to this parallel
install failure.

Interestingly, libgcc appears to run make in non-parallel
mode?

make[3]: Entering directory `x86_64-unknown-linux-gnu/libgcc'
make[3]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rul
e.


-- 
           Summary: GCC parllel "make install" failures
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980