* "already configured" for dejagnu after gmake distclean. @ 2004-03-25 15:57 Hugh Sasse Staff Elec Eng 2004-03-25 19:53 ` Dave Korn 0 siblings, 1 reply; 5+ messages in thread From: Hugh Sasse Staff Elec Eng @ 2004-03-25 15:57 UTC (permalink / raw) To: Binutils list 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. Thank you, Hugh -------------- #!/bin/sh -vx date + date Thu Mar 25 12:54:13 WET 2004 CC=gcc; export CC CC=gcc + export CC echo $CC + echo gcc gcc $CC --version + gcc --version gcc (GCC) 3.3.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. MAKE=gmake; export MAKE MAKE=gmake + export MAKE echo $MAKE + echo gmake gmake $MAKE --version + gmake --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [...] TCL_LIBRARY=/usr/local/lib/tcl8.3; export TCL_LIBRARY TCL_LIBRARY=/usr/local/lib/tcl8.3 + export TCL_LIBRARY echo $TCL_LIBRARY + echo /usr/local/lib/tcl8.3 /usr/local/lib/tcl8.3 DEJAGNULIBS=/usr/local/share/dejagnu; export DEJAGNULIBS DEJAGNULIBS=/usr/local/share/dejagnu + export DEJAGNULIBS echo $DEJAGNULIBS + echo /usr/local/share/dejagnu /usr/local/share/dejagnu WITH_LD='--with-ld=/usr/local/bin/ld --with-gnu-ld' WITH_LD=--with-ld=/usr/local/bin/ld --with-gnu-ld WITH_AS='--with-as=/usr/local/bin/as --with-gnu-as' WITH_AS=--with-as=/usr/local/bin/as --with-gnu-as /usr/local/bin/ld --version + /usr/local/bin/ld --version GNU ld version 2.12.1 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. /usr/local/bin/as --version + /usr/local/bin/as --version GNU assembler 2.12.1 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.9'. uname -a + uname -a SunOS brains 5.9 Generic_112233-06 sun4u sparc SUNW,Sun-Blade-100 cd /export/home/Scratch/hgs/binutils-cvs/build + cd /export/home/Scratch/hgs/binutils-cvs/build gmake distclean + gmake distclean [...] Doing distclean in dejagnu gmake[1]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu' Making distclean in . gmake[2]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu' rm -f TAGS ID rm -f Makefile rm -f config.cache config.log stamp-h stamp-h[0-9]* test -z "x.log x.sum site.bak setval.tmp" || rm -f x.log x.sum site.bak setval.tmp cd doc ; gmake clean gmake[3]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/doc' rm -fr overview.html overview.ps overview.pdf overview.rtf DBHTOHTML* overview.junk overview overview.{aux,dvi,log,ps,pdf,tex} gmake[3]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/doc' cd testsuite ; gmake clean gmake[3]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite' Making clean in . gmake[4]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite' test -z "*.log *.sum site.bak setval.tmp" || rm -f *.log *.sum site.bak setval.tmp gmake[4]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite' Making clean in libdejagnu gmake[4]: Entering directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite/libdejagnu' test -z "unit" || rm -f unit rm -f *.o core *.core gmake[4]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite/libdejagnu' gmake[3]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/testsuite' cd example ; gmake clean 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' 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. gmake[4]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example/calc' gmake[3]: *** [clean-recursive] Error 1 gmake[3]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu/example' gmake[2]: *** [clean-local] Error 2 gmake[2]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu' gmake[1]: *** [distclean-recursive] Error 1 gmake[1]: Leaving directory `/export/home/Scratch/hgs/binutils-cvs/build/dejagnu' gmake: *** [distclean-dejagnu] Error 1 cd ../src + cd ../src cvs update -d + cvs update -d cd .. [...] + cd .. echo "Completely clear out build directory, including .files..." + echo Completely clear out build directory, including .files... Completely clear out build directory, including .files... /bin/rm -rf ./build + /bin/rm -rf ./build mkdir build + mkdir build cd build + cd build echo "Now in `pwd`" + pwd + echo Now in /export/home/Scratch/hgs/binutils-cvs/build Now in /export/home/Scratch/hgs/binutils-cvs/build ../src/configure $WITH_LD $WITH_AS --prefix=/scratch/hgs/local + ../src/configure --with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as --with-gnu-as --prefix=/scratch/hgs/local [...] Configuring in dejagnu creating cache ./config.cache checking for a BSD compatible install... ../../src/dejagnu/install-sh -c checking whether build environment is sane... yes checking whether gmake sets ${MAKE}... yes checking for working aclocal... missing checking for working autoconf... found checking for working automake... missing checking for working autoheader... found checking for working makeinfo... found checking whether to enable maintainer-specific portions of Makefiles... no checking whether gmake sets ${MAKE}... (cached) yes checking for gcc... gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for c++... CC checking whether the C++ compiler (CC -g -O2 ) works... yes checking whether the C++ compiler (CC -g -O2 ) is a cross-compiler... no checking whether we are using GNU C++... no checking whether CC accepts -g... yes checking for a BSD compatible install... ../../src/dejagnu/install-sh -c checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no checking for bison... bison -y checking for docbook tools... none checking for the tclsh program... none checking for tclsh... /usr/local/bin/tclsh updating cache ./config.cache creating ./config.status creating Makefile creating doc/Makefile creating testsuite/Makefile creating example/Makefile creating testsuite/libdejagnu/Makefile configuring in example/calc running /bin/sh ../../../../src/dejagnu/example/calc/configure --build=sparc-sun-solaris2.9 --host=sparc-sun-solaris2.9 --target=sparc-sun-solaris2.9 --with-gnu-as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as --with-gnu-as --prefix=/scratch/hgs/local --program-transform-name=s,y,y, --cache-file=../.././config.cache --srcdir=../../../../src/dejagnu/example/calc loading cache ../.././config.cache checking for a BSD compatible install... ../../../../src/dejagnu/example/calc/../../install-sh -c checking whether build environment is sane... yes checking whether gmake sets ${MAKE}... (cached) yes configure: error: source directory already configured; run make distclean there first configure: error: ../../../../src/dejagnu/example/calc/configure failed for example/calc gmake: *** [configure-dejagnu] Error 1 + exit 1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: "already configured" for dejagnu after gmake distclean. 2004-03-25 15:57 "already configured" for dejagnu after gmake distclean Hugh Sasse Staff Elec Eng @ 2004-03-25 19:53 ` Dave Korn 2004-03-29 16:46 ` Hugh Sasse Staff Elec Eng 0 siblings, 1 reply; 5+ messages in thread From: Dave Korn @ 2004-03-25 19:53 UTC (permalink / raw) To: 'Binutils list' > -----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.... ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: "already configured" for dejagnu after gmake distclean. 2004-03-25 19:53 ` Dave Korn @ 2004-03-29 16:46 ` Hugh Sasse Staff Elec Eng 2004-03-29 18:00 ` Dave Korn 0 siblings, 1 reply; 5+ messages in thread From: Hugh Sasse Staff Elec Eng @ 2004-03-29 16:46 UTC (permalink / raw) To: Dave Korn; +Cc: 'Binutils list' On Thu, 25 Mar 2004, Dave Korn wrote: > > > -----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 [helpful comments elided] > 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: > > > Why don't you do what the error message advises, and "make distclean" in I did actually do that before any attempts to build in a new directory, because before I was building in the source tree. [various ways of deleting the unwanted files trimmed] Thanks for those. I did the most drastic thing, and /bin/rm -rf src and re-got it from the cvs. This has helped considerably, the build continues much longer before it fails. I'm starting a new thread on that because it is not related to dejagnu. > > 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 I am absolutely positive that I did that distclean in between, forseeing this problem if I didn't. It is well over a week ago though, and I don't have any evidence lying around to prove this. If it would help the code base become even more stable I could rewrite my script to delete the src directory, get a fresh one, build in that, `gmake distclean` and build in a parallel dir, to rigorously test this. I expect the development team would not put a high value on the test results, though, because it is considered a rare case. If it would help prove things, or act as a "unit test" for configure and/or make distclean, I'd be happy to contribute that on the basis that it may the time of peole trying to build binutils, and the time of people (such as yourself) who are generous enough to advise the likes of me in such matters. > 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. I'd suggest that this is more common than might be thought, because it is one of the often-suggested remedies to an unsuccessful build, that the build should be done in a different directory. This is going from what I have seen on gcc, binutils lists, anyway. > > > > cheers, > DaveK Thank you, again, Hugh ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: "already configured" for dejagnu after gmake distclean. 2004-03-29 16:46 ` Hugh Sasse Staff Elec Eng @ 2004-03-29 18:00 ` Dave Korn 2004-03-29 18:53 ` Hugh Sasse Staff Elec Eng 0 siblings, 1 reply; 5+ messages in thread From: Dave Korn @ 2004-03-29 18:00 UTC (permalink / raw) To: 'Binutils list' > -----Original Message----- > From: Hugh Sasse Staff Elec Eng > Sent: 29 March 2004 16:48 > > state; you must have not distcleaned between the two > configures, and > > now you have makefiles > > I am absolutely positive that I did that distclean in > between, forseeing this problem if I didn't. It is well over > a week ago though, and I don't have any evidence lying around > to prove this. Well, it pretty much has to be the case; the evidence is all those generated files that were showing up as being in your source tree when you did the cvs update. Every single one of those lines beginning '?' should not have been there. Perhaps you did the reconfigure, then belatedly remembered about distclean and ran it, then re-reconfigured; if you'd already started the reconfigure, however, it might have already rewritten the makefiles so that by the time you did the distclean it was deleting stuff from the object dir not the source dir. It's hard to know how it first went wrong, but that's certainly the state it ended up in. > > 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. > > I'd suggest that this is more common than might be thought, > because it is one of the often-suggested remedies to an > unsuccessful build, that the build should be done in a > different directory. This is going from what I have seen on > gcc, binutils lists, anyway. I'm in full agreement with you. AFAIC configure should flat-out refuse to run in the source tree. It's nothing but a source of trouble and confusion. It could even be the case that 'make distclean' has a bug in it and hasn't been working properly when run in the source dir for some time, but nobody's noticed.... cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: "already configured" for dejagnu after gmake distclean. 2004-03-29 18:00 ` Dave Korn @ 2004-03-29 18:53 ` Hugh Sasse Staff Elec Eng 0 siblings, 0 replies; 5+ messages in thread From: Hugh Sasse Staff Elec Eng @ 2004-03-29 18:53 UTC (permalink / raw) To: Dave Korn; +Cc: 'Binutils list' On Mon, 29 Mar 2004, Dave Korn wrote: > > > -----Original Message----- > > From: Hugh Sasse Staff Elec Eng > > Sent: 29 March 2004 16:48 > > > > state; you must have not distcleaned between the two > > configures, and > > > now you have makefiles > > > > I am absolutely positive that I did that distclean in > > between, forseeing this problem if I didn't. It is well over > > a week ago though, and I don't have any evidence lying around > > to prove this. > > Well, it pretty much has to be the case; the evidence is all those > generated files that were showing up as being in your source tree when you > did the cvs update. Every single one of those lines beginning '?' should > not have been there. Perhaps you did the reconfigure, then belatedly > remembered about distclean and ran it, then re-reconfigured; if you'd I don't think so, because I know that configure creates the makefiles that would be used by the subsequent make. > already started the reconfigure, however, it might have already rewritten > the makefiles so that by the time you did the distclean it was deleting > stuff from the object dir not the source dir. It's hard to know how it > first went wrong, but that's certainly the state it ended up in. > > > > 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. > > > > I'd suggest that this is more common than might be thought, > > because it is one of the often-suggested remedies to an [...] > > I'm in full agreement with you. AFAIC configure should flat-out refuse to > run in the source tree. It's nothing but a source of trouble and confusion. > It could even be the case that 'make distclean' has a bug in it and hasn't > been working properly when run in the source dir for some time, but nobody's > noticed.... Would it be of any help to test this out, and point people at the results? I'm willing to do that. > > > cheers, > DaveK ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-03-29 17:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-03-25 15:57 "already configured" for dejagnu after gmake distclean Hugh Sasse Staff Elec Eng 2004-03-25 19:53 ` Dave Korn 2004-03-29 16:46 ` Hugh Sasse Staff Elec Eng 2004-03-29 18:00 ` Dave Korn 2004-03-29 18:53 ` Hugh Sasse Staff Elec Eng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).