From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29504 invoked by alias); 6 Dec 2011 22:44:39 -0000 Received: (qmail 29400 invoked by uid 22791); 6 Dec 2011 22:44:35 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Dec 2011 22:44:21 +0000 From: "davek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib} Date: Tue, 06 Dec 2011 22:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: davek at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Target Status Last reconfirmed CC Version Resolution Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00679.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D38388 Dave Korn changed: What |Removed |Added ---------------------------------------------------------------------------- Target|x86_64-gnu-linux | Status|RESOLVED |REOPENED Last reconfirmed| |2011-12-06 CC| |davek at gcc dot gnu.org Version|4.4.0 |4.7.0 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #9 from Dave Korn 2011-12-06 22:43:4= 6 UTC --- [ Reopened because the gnatlib bug is still present. Removed target, becau= se it is not target-specific. Not sure if bootstrap is still the right compon= ent or if it should be ada, so will leave that to discretion of bug maintainers= . ] I saw this myself earlier, and asked about it on the GCC list at http://gcc.gnu.org/ml/gcc/2011-12/msg00050.html -=20 On 03/12/2011 12:16, Dave Korn wrote: > Running "make -j8 install" in a fresh build of head, I saw loads of the > following error messages coming out in the log: >=20 >> cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a= -ztmoau.adb': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a= -ztmoio.adb': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a= -zttest.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a= -zzboio.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a= da.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/d= irectio.ads': >> File exists > [ ... snip ... ] >=20 > Sure enough, all the files did exist, so I guess it must have been tryi= ng to > install them twice. Before I try digging deeper, I thought I'd quickly a= sk: > Does anyone else see this? (Is it perhaps something that wouldn't show u= p on > a different host, such as linux, owing to differing filesystem semantics?) Okay, confirmed; I wonder why this isn't causing problems for anyone else? The issue is that there are two dependency chains that lead to the "install-gnatlib" target in the gcc/ada/gcc-interface/Makefile.in-derived Makefile in $objdir: [1] top level "make install" -> $objdir/$target/libada/Makefile "install: install-gnatlib" -> "install-gnatlib:" -> $objdir/gcc/ada/Makefile(*) "install-gnatlib:" -> $objdir/gcc/ada/gcc-interface/Makefile "install-gnatlib:". [2] top level "make install" -> $objdir/gcc/Makefile "install: install-comm= on" -> "install-common: lang.install-common" -> "lang.install-common: ada.install-common" -> $(srcdir)/ada/gcc-interface/Make-lang.in "ada.install-common" -> "install-gnatlib" -> $objdir/gcc/ada/Makefile(*) "install-gnatlib:" -> $objdir/gcc/ada/gcc-interface/Makefile "install-gnatlib:". The two paths merge at (*), and so a parallel top-level make can end up running both of them at the same time. That gets broken, because the install-gnatlib target begins by wiping and recreating the install dirs: > install-gnatlib: ../stamp-gnatlib-$(RTSDIR) > # Create the directory before deleting it, in case the directory is > # a list of directories (as it may be on VMS). This ensures we are > # deleting the right one. > -$(MKDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) > $(RMDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > $(RMDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) Depending how out-of-sync the two separate sub-makes are, this results in= an incomplete installation. Here's what happened in my latest test: > make[2]: Entering directory `/gnu/gcc/obj3/i686-pc-cygwin/libada' > make -C ../.././gcc/ada "MAKEOVERRIDES=3D" "LDFLAGS=3D" "LN_S=3Dln -s" "S= HELL=3D/bin/sh" "GNATLIBFLAGS=3D-W -Wall -gnatpg -nostdinc " "GNATLIBCFLAGS= =3D-g -O2 " "GNATLIBCFLAGS_FOR_C=3D-W -Wall -g -O2 -fexceptions -DIN_RTS -= DHAVE_GETIPINFO " "PICFLAG_FOR_TARGET=3D" "THREAD_KIND=3Dnative" "TRACE=3Dn= o" "MULTISUBDIR=3D" "libsubdir=3D/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0" "ob= jext=3D.o" "prefix=3D/gnu/usr" "exeext=3D.exeext.should.not.be.used " 'CC= =3Dthe.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=3D/gnu/gcc/obj3/= ./gcc/xgcc -B/gnu/gcc/obj3/./gcc/ -B/gnu/usr/i686-pc-cygwin/bin/ -B/gnu/usr= /i686-pc-cygwin/lib/ -isystem /gnu/usr/i686-pc-cygwin/include -isystem /gnu= /usr/i686-pc-cygwin/sys-include " "CFLAGS=3D-g -O2" install-gnatlib > make[3]: Entering directory `/gnu/gcc/obj3/gcc/ada' > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adain= clude > rm -rf /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib > rm -rf /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adaincl= ude > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adain= clude > for file in rts/*.ali; do \ > cp -p $file /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7= .0/adalib; \ > done The target libada make install runs first, recurses into gcc/ada and star= ts copying .ali files. Shortly afterwards, ... > make[4]: Entering directory `/gnu/gcc/obj3/gcc/ada' > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib > mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adain= clude ... make install running in the gcc subdir starts running the install-gnatl= ib target too, ... > rm -rf /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib > rm: cannot remove `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4= .7.0/adalib': Directory not empty > make[4]: *** [install-gnatlib] Error 1 > make[4]: Leaving directory `/gnu/gcc/obj3/gcc/ada' > make[3]: *** [install-gnatlib] Error 2 > make[3]: Leaving directory `/gnu/gcc/obj3/gcc' ... and fails, but not after having deleted all the files that the target libada make had managed to install so far. > cd rts; for file in *.a;do \ > /usr/bin/install -c -m 644 $file /gnu/gcc/install.obj3/gnu/usr/lib/g= cc/i686-pc-cygwin/4.7.0/adalib; \ > /gnu/usr/i686-pc-cygwin/bin/ranlib /gnu/gcc/install.obj3/gnu/usr/lib= /gcc/i686-pc-cygwin/4.7.0/adalib/$file; \ > done Meanwhile the target libada install continues to run... > if [ -f gcov.exe ]; \ > then \ > rm -f /gnu/gcc/install.obj3/gnu/usr/bin/gcov-4.exe; \ > /usr/bin/install -c gcov.exe /gnu/gcc/install.obj3/gnu/usr/bin/gcov-= 4.exe; \ > fi > make[2]: Leaving directory `/gnu/gcc/obj3/gcc' > make[1]: Leaving directory `/gnu/gcc/obj3' >=20 > real 7m48.235s > user 4m48.897s > sys 3m35.738s ... and eventually the top-level make completes - apparently without error,= so I guess the lower-level $objdir/gcc/ada make isn't propagating errors back = up properly. I hope a build-system maintainer can advise. Would removing the install-gnatlib from the gcc/ada language directory and having the files installed only from the $target/libada directory be correct w.r.t multilibs?