From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10063 invoked by alias); 6 Dec 2002 00:45:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10055 invoked from network); 6 Dec 2002 00:45:56 -0000 Received: from unknown (HELO mailout6-0.nyroc.rr.com) (24.92.226.125) by sources.redhat.com with SMTP; 6 Dec 2002 00:45:56 -0000 Received: from doctormoo (syr-24-24-16-193.twcny.rr.com [24.24.16.193]) by mailout6-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gB60jrk22994; Thu, 5 Dec 2002 19:45:54 -0500 (EST) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 18K6bz-00035u-00; Thu, 05 Dec 2002 19:44:59 -0500 Date: Thu, 05 Dec 2002 16:54:00 -0000 To: ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: (toplevel patch) Configure in Makefile, version 3. Message-ID: <20021206004458.GA11878@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-12/txt/msg00217.txt.bz2 > Ok, now that I've recovered from my `pleasant suprise' :-) I'm finding >that, given a build that barfs in GDB, it tries to re-configure BFD >when >re-made. > > It's being run with `gmake -k -j 2'. Anyone else noticed this? Not me. Have you got it working when the build doesn't crash in gdb?... I've done oodles of builds with the current versions of the files, but I'm sure there are builds I haven't tried. :-/ The only reasons it should try to reconfigure BFD are: * bfd/Makefile was changed (or 'touch'ed) by something * libiberty/Makefile was changed (or 'touch'ed) by something * config.status at the top level was changed (or 'touch'ed) by something I can't imagine why either of those things would happen. Is it really a problem, anyway? BFD is reconfigured with the same arguments it was configured with the previous time... It *will* try to rebuild BFD. That is correct. BFD's Makefile should be clever enough to do nothing in this case, though it might not be. Hmm. When GNU make runs BFD's Makefile, maybe BFD's Makefile decides that it's out of date? I haven't poked BFD's Makefile enough. Can you figure out which level of Make is trying to rebuild BFD's Makefile? --Nathanael