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
