Re: configure problem

[Andrew Cagney <ac131313@cygnus.com>]

Braxton Thomason wrote:
> 
> I recently d/led a release of insight/gdb and am having a configure
> problem.  When I run configure in the base directory, I get the following
> error:
> 
> loading cache ../config.cache within ltconfig
> ./../ltconfig: ./../ltcf-c.sh: No such file or directory
> configure: error: libtool configure failed
> Configure in /usr/src/insight+dejagnu-20000924/opcodes failed, exiting.
> 
> The contents of config.status is
> ./configure --host=i586-pc-linux-gnu --norecursion
> 
> Am I missing some important file?

Yes.  This should be fixed in the current snapshot:

$ bunzip2 < insight+dejagnu-20000926.tar.bz2| tar tf - | grep ltcf  
insight+dejagnu-20000926/ltcf-c.sh

	Andrew
From jingham@apple.com Tue Sep 26 18:32:00 2000
From: Jim Ingham <jingham@apple.com>
To: Vardhan Varma <vardhan@cadence.com>
Cc: gdb@sources.redhat.com
Subject: Re: wishlist for gdb ....
Date: Tue, 26 Sep 2000 18:32:00 -0000
Message-id: <200009270132.SAA08066@scv2.apple.com>
References: <970017094.31332.ezmlm@sources.redhat.com>
X-SW-Source: 2000-09/msg00149.html
Content-length: 2142

Vardhan,

>  
>        Here are some magic possible, by ksh integration , 
>        i would like to know how to achieve similar things in 
>        gdb. 
>  
>     1. (dbx) $(funcs .*foo.*bar.* | sed 's/^/stop in/') 
>        this will set break points in all  
>        functions matching .*foo.*bar !!! 
>        (okay not exactly this, but something similar (-; ) 

The gdb command shell is not a real command interpreter, so you can't do neato programming stuff like this.  However, you can achieve this particular task using the "rbreak" command, which takes as its argument a regular expression, and sets a breakpoint on all the functions that match that regular expression.  In this particular case, rbreak is neater that what is given above, but clearly the programmability is more powerful in the long run.

Another option is to run Insight, which contains a full Tcl interpreter, including a bunch of commands wired into the guts of gdb for accessing variables, registers, etc, and an out to the gdb command set which returns the output in the result of the Tcl command so that you can capture and act on it further.  This is actually a pretty powerful environment (though somewhat poorly documented - sigh...).

In the long run, it would be nice to split the Tcl-only part of insight out from the Tk parts, so you could run Tcl as the command interpreter for gdb.  Someday, I will find the time to do this, but I haven't yet...

>  
>    2.  how to grep help's output ?? 
>        help show | grep arg ????? 
>        or even setenv PAGER=xless displays help in seperate 
>        xless window. 
>  

In this case do something like:

(gdb) tk exec grep arg [gdb_cmd {help show}]  

plus or minus a little tweaking will do what you want...  You could also write the search as a Tcl proc, and run that.  The only bogosity about the console window is that its line wrapping follows the gdb command language rules, not the Tcl ones, so any complicated command has to be put into a file, and sourced, as in:

(gdb) tk source defines_search_proc.tcl
(gdb) tk search_proc arg [gdb_cmd "help show"]

or whatever...

Hope this helps,

Jim