"already configured" for dejagnu after gmake distclean.

"already configured" for dejagnu after gmake distclean.

[Hugh Sasse Staff Elec Eng]

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

RE: "already configured" for dejagnu after gmake distclean.

[Dave Korn]

> -----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....
 

RE: "already configured" for dejagnu after gmake distclean.

[Hugh Sasse Staff Elec Eng]

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

RE: "already configured" for dejagnu after gmake distclean.

[Dave Korn]

> -----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....

RE: "already configured" for dejagnu after gmake distclean.

[Hugh Sasse Staff Elec Eng]

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