This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: possible race condition in make install?
- From: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- To: gcc at gcc dot gnu dot org
- Cc: mikestump at comcast dot net, iains at gcc dot gnu dot org, dominiq at lps dot ens dot fr
- Date: Sat, 16 Jul 2011 16:53:20 -0400
- Subject: Re: possible race condition in make install?
- References: <20110716204022.GA29419@bromo.med.uc.edu>
On Sat, Jul 16, 2011 at 04:40:22PM -0400, Jack Howarth wrote:
> I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink which I've reproduced
> myself. The failure looks quite odd...
>
> /usr/bin/install -c -m 644 ./libiberty.a /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2 -print-multi-os-directory`/./libiberty.an
> mkdir /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW
> mkdir /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW/LC_MESSAGES
> libtool: install: /usr/bin/install -c .libs/libssp.0.dylib /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.0.dylib
> libtool: install: (cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64 && { ln -s -f libssp.0.dylib libssp.dylib || { rm -f libssp.dylib && ln -s libssp.0.dylib libssp.dylib; }; })
> libtool: install: /usr/bin/install -c .libs/libssp.lai /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.la
> libtool: install: /usr/bin/install -c .libs/libssp.a /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> ( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
> libtool: install: chmod 644 /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> ranlib: file: ./libiberty.an is not an archive
> libtool: install: ranlib -c /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> make[2]: *** [install_to_libdir] Error 1
> make[1]: *** [install-libiberty] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> and only occurs with parallel builds. Is it possible that the command...
>
> /usr/bin/install -c -m 644 ./libiberty.a /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2 -print-multi-os-directory`/./libiberty.an
>
> could be in a race condition with the later command...
>
> ( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
>
> if so what can be done about this. So far the only work around I've found is to use the --disable-java-multilib patch ala redhat
> which seems to cause this issue to go latant again. Any ideas?
> Jack
Also, I assume that this issue is coming from gcc-4.4.6/libiberty/Makefile.in at this section...
# This is tricky. Even though CC in the Makefile contains
# multilib-specific flags, it's overridden by FLAGS_TO_PASS from the
# default multilib, so we have to take CFLAGS into account as well,
# since it will be passed the multilib flags.
MULTIOSDIR = `$(CC) $(CFLAGS) -print-multi-os-directory`
install_to_libdir: all
${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR)
$(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n
( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n ;$(RANLIB) $(TARGETLIB)n )
mv -f $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)
if test -n "${target_header_dir}"; then \
case "${target_header_dir}" in \
/*) thd=${target_header_dir};; \
*) thd=${includedir}/${target_header_dir};; \
esac; \
${mkinstalldirs} $(DESTDIR)$${thd}; \
for h in ${INSTALLED_HEADERS}; do \
${INSTALL_DATA} $$h $(DESTDIR)$${thd}; \
done; \
fi
@$(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=install
I'm not very familar with the finer points of adjusting Makefile.in's to be parallel make friendly.
What keeps...
$(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n
from outrunning the execution of the next command...
( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n ;$(RANLIB) $(TARGETLIB)n )
on a multiprocessor machine with parallel make?
Jack