public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Dave Korn" <dk@artimi.com>
To: "'Binutils list'" <binutils@sources.redhat.com>
Subject: RE: "already configured" for dejagnu after gmake distclean.
Date: Thu, 25 Mar 2004 19:53:00 -0000	[thread overview]
Message-ID: <NUTMEGxRVVfdY6hlHK900000234@NUTMEG.CAM.ARTIMI.COM> (raw)
In-Reply-To: <Pine.GSO.4.58.0403251404520.5832@brains>


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

  reply	other threads:[~2004-03-25 15:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-25 15:57 Hugh Sasse Staff Elec Eng
2004-03-25 19:53 ` Dave Korn [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=NUTMEGxRVVfdY6hlHK900000234@NUTMEG.CAM.ARTIMI.COM \
    --to=dk@artimi.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).