From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21392 invoked by alias); 29 Feb 2008 01:10:38 -0000 Received: (qmail 21381 invoked by uid 22791); 29 Feb 2008 01:10:37 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Feb 2008 01:10:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8CB8B2A9F52 for ; Thu, 28 Feb 2008 20:10:18 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ibCJAq58tl+5 for ; Thu, 28 Feb 2008 20:10:18 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4DEA92A9F50 for ; Thu, 28 Feb 2008 20:10:18 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id DBC84E7ACB; Thu, 28 Feb 2008 17:10:15 -0800 (PST) Date: Fri, 29 Feb 2008 04:38:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: is --with-libexpat-prefix broken? NOT! Message-ID: <20080229011015.GJ19729@adacore.com> References: <20080227234911.GC19729@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080227234911.GC19729@adacore.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00254.txt.bz2 > I'm looking into it, but it's really puzzling. It looks like this > part is taken care of by config/lib-link.m4:AC_LIB_HAVE_LINKFLAGS. > And yet, I don't see a change since 6.7.1 that could likely be > responsible for this change of behavior. I think I understand what's going on, now. My checkout was, for some reason, missing a bunch of files in the root directory, one of them being config.rpath. I do regular "cvs update" on my sandbox, but these files don't seem to get restored by this command - I had to explicitly request the update of config.rpath to see it being restored. So what I did was do a clean checkout of the sources, which did contain the missing files - and things went back to normal. If someone else has the same problem, I hope this helps... -- Joel