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
