This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: possible race condition in make install?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]