From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29750 invoked by alias); 27 Feb 2008 23:49:33 -0000 Received: (qmail 29741 invoked by uid 22791); 27 Feb 2008 23:49:33 -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; Wed, 27 Feb 2008 23:49:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4B5892AA1BA for ; Wed, 27 Feb 2008 18:49:14 -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 voX4qIMrdg+s for ; Wed, 27 Feb 2008 18:49:14 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 133252AA1B8 for ; Wed, 27 Feb 2008 18:49:14 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id E3015E7ACB; Wed, 27 Feb 2008 15:49:11 -0800 (PST) Date: Thu, 28 Feb 2008 00:32:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: is --with-libexpat-prefix broken? Message-ID: <20080227234911.GC19729@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00240.txt.bz2 It looks like it: I tried configuring GDB on sparc-solaris using: --with-libexpat-prefix=/nile.build/brobecke/exp/libexpat, where /nile.build/brobecke/exp/libexpat is the prefix where I have previously installed libexpat. With gdb-6.7.1, configuring GDB with this --with-libexpat-prefix was sufficient. The config.log showed: > configure:6327: checking for libexpat > configure:6351: gcc -o conftest -g -I/nile.build/brobecke/exp/libexpat/include conftest.c -lncurses -lsocket -lnsl -lm /nile.build/brobecke/exp/libexpat/lib/libexpat.a >&5 > configure:6357: $? = 0 So as you can see, the path to libexpat was automatically provided to the GCC command. (the command also shows that I only built the libexpat archive, but that's just a detail) With the latest sources, I don't see the -I switch anymore, and I don't see the path to the archive either. All I see is that configure tries to build using -lexpat without specifying where the includes or the library might be found: > configure:7028: checking for libexpat > configure:7052: gcc -o conftest -g conftest.c -lncurses -lsocket -lnsl -lm -lexpat >&5 > ld: fatal: library -lexpat: not found > ld: fatal: File processing errors. No output written to conftest > collect2: ld returned 1 exit status 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. Am I the only who sees this? Perhaps it's pilot error on my end, although I seem to be following the documentation says I need to do. Thanks, -- Joel