From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4375 invoked by alias); 20 Dec 2005 10:45:00 -0000 Received: (qmail 4368 invoked by uid 22791); 20 Dec 2005 10:44:59 -0000 X-Spam-Check-By: sourceware.org Received: from smtp12.wanadoo.fr (HELO smtp12.wanadoo.fr) (193.252.22.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Dec 2005 10:44:56 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1206.wanadoo.fr (SMTP Server) with ESMTP id 47E811C0009D for ; Tue, 20 Dec 2005 11:44:54 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-18-214.w81-248.abo.wanadoo.fr [81.248.215.214]) by mwinf1206.wanadoo.fr (SMTP Server) with ESMTP id CF24B1C00057; Tue, 20 Dec 2005 11:44:53 +0100 (CET) X-ME-UUID: 20051220104453848.CF24B1C00057@mwinf1206.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id AB82947E79; Tue, 20 Dec 2005 14:44:50 +0400 (RET) Date: Tue, 20 Dec 2005 10:45:00 -0000 From: Joel Brobecker To: Petchesi Gabriel Horatiu Cc: gdb@sources.redhat.com Subject: Re: gdb on AIX Message-ID: <20051220104450.GO31944@adacore.com> References: <1134986205.16296.30.camel@localhost.localdomain> <20051219111902.GD31944@adacore.com> <1135069892.18884.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135069892.18884.6.camel@localhost.localdomain> User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00163.txt.bz2 > I found this in gdbgdb/config.log subdir > .... > configure:7550: checking for main in -lm > configure:7606: result: no This is incomplete. Did you get this after a first configure run, or did you do a reconfigure. For instance, I checked in one of the builds we have here, and I see: configure:7550: checking for main in -lm configure:7574: gcc -o conftest -g -D_LONG_LONG conftest.c -lm >&5 configure:7580: $? = 0 configure:7584: test -z || test ! -s conftest.err configure:7587: $? = 0 configure:7590: test -s conftest configure:7593: $? = 0 configure:7606: result: yes I do get the same result as you, however, if I do a second configure over an already configured directory. What happens is that configure then uses the cache instead of recomputing everything. The part of configure that does this checking is right after: # ---------------------- # # Checks for libraries. # # ---------------------- # # We might need to link with -lm; most simulators need it. In particular, I see: else echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 So in your case where the result is "no", you should get two things: The full listing of the program that configure tried to compile and GCC failed to build, and just before that, the actual error printed by the compiler. Short of that, I can only suggest to dive into the configure script and add some traces to help you find the source of your problem. You may also try to do a make LDFLAGS="-lm" That will just work-around your problem, but perhaps you'll be able to get a debugger in the meantime. -- Joel