From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22811 invoked by alias); 25 Mar 2004 15:04:34 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 22752 invoked from network); 25 Mar 2004 15:04:32 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sources.redhat.com with SMTP; 25 Mar 2004 15:04:32 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 15:03:38 +0000 From: "Dave Korn" To: "'Binutils list'" Subject: RE: "already configured" for dejagnu after gmake distclean. Date: Thu, 25 Mar 2004 19:53:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: X-OriginalArrivalTime: 25 Mar 2004 15:03:38.0875 (UTC) FILETIME=[5A9CC4B0:01C4127A] X-SW-Source: 2004-03/txt/msg00562.txt.bz2 > -----Original Message----- > From: binutils-owner On Behalf Of Hugh Sasse Staff Elec Eng > Sent: 25 March 2004 14:30 > I'm still getting errors with dejagnu, when building binutils (CVS) > from scratch. > > See: > http://www.eng.cse.dmu.ac.uk/~hgs/binutils-cvs-failure.txt > > for the full details... > > edited highlights of which are below. You *still* aren't building it from scratch. Your source tree is *still* full of generated files, as the "cvs update" output shows. The reason that your source tree is *still* full of generated files is because your "make distclean" is *still* failing with an error part-way through. Notice how the first few lines of the error show that there's a clash between multiple makefiles: gmake[3]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example' Makefile:318: warning: overriding commands for target `check-recursive' Makefile:112: warning: ignoring old commands for target `check-recursive' Making clean in . gmake[4]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example' Makefile:318: warning: overriding commands for target `check-recursive' Makefile:112: warning: ignoring old commands for target `check-recursive' gmake[4]: Nothing to be done for `clean-am'. gmake[4]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example' and then there's a total lack of makefile where one is expected: Making clean in calc gmake[4]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example/calc' gmake[4]: *** No rule to make target `clean'. Stop. And because this fails, the cleaning doesn't complete, and you later get the error: configure: error: source directory already configured; run make distclean there first configure: error: ../../../../src/dejagnu/example/calc/configure failed for example/calc As we see, in your source tree you have lots of generated files that shouldn't be there, and they are presumably wreaking havoc with the generated files in your build tree: ? dejagnu/example/Makefile ? dejagnu/example/calc/config.log ? dejagnu/example/calc/calc.h ? dejagnu/example/calc/config.status ? dejagnu/example/calc/stamp-h ? dejagnu/example/calc/.deps ? dejagnu/example/calc/Makefile ? dejagnu/testsuite/Makefile ? dejagnu/testsuite/libdejagnu/Makefile ? dejagnu/testsuite/libdejagnu/.deps Why don't you do what the error message advises, and "make distclean" in the *source* directory for dejagnu? Or just cut and paste the output from CVS where it lists all the new files into a shell with 'rm'? Or something like this: cd src; cvs -q update | grep ^\? | cut -d ' ' -f2- | xargs rm which will automatically delete everything but the actual CVS sources from your tree (watch out if you've deliberately left some of your own files in there!) The underlying problem is that you've first configured in the source directory and then tried to reconfigure for a parallel object directory build, and it's gotten your source tree into an inconsistent state; you must have not distcleaned between the two configures, and now you have makefiles in the source tree where they shouldn't be. GNU source code is designed to be built either in a parallel directory or in the source directory itself, but it's not designed to switch from one method to the other; when configure is running in your new parallel object directory for the first time, it doesn't know about the previous configuration because the config.status and other files have ended up in the source tree. In theory, configure could be protected against this, detect when generated files were found in the source tree, and automatically do a distclean itself, but people don't often tend to switch from the one style of building to the other, so it hasn't been done. cheers, DaveK -- Can't think of a witty .sigline today....