Re: fwd: fixing some FIXMEs

[Eli Zaretskii <eliz@delorie.com>]

> Date: Mon, 8 Jan 2001 21:04:32 -0500
> From: Phil Edwards <pedwards@disaster.jaj.com>
> 
> I ran into these two FIXMEs in the top-level configury.  The one which
> tests the host is moved into the per-host section, and the one which sets
> up GDB_TK is moved into the per-target section.
> 
> Opinions?  Comments?

I'd need to see the regenerated configure script to judge whether this
is okay for the DJGPP port.  (I don't have Autoconf installed and
don't have time to futz with it, sorry.)
From fnasser@redhat.com Tue Jan 09 03:25:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gdb@sources.redhat.com
Subject: Re: _status: no such variable
Date: Tue, 09 Jan 2001 03:25:00 -0000
Message-id: <3A5AF4D3.67766B18@redhat.com>
References: <20010108234026.A450@disaster.jaj.com>
X-SW-Source: 2001-01/msg00022.html
Content-length: 2373

Phil Edwards wrote:
> 
> Firing up current CVS's insight hangs the source window, with the console
> window containing:
> 

No matter what I do I cannot reproduce this.  It just works fine for me
under
several different circumstances.  And I have it on different machines,
different OS versions...  And I've been just talking with some other
folks who
just built it all right.

Furthermore, this stack trace describes an impossible situation. 
"_status" is
where the Source Window stores the name of the label widget that is used
for
status and help information (at the bottom).  Regardless of the success
or not
of the creation of this widget the variable should exist. "no such
variable" is
just absurd.

There are two possibilities remaining:

1) Your cvs checkout went terribly wrong.  A fresh checkout should fix
it.

2) You are loading some program (you called GDB with an executable name
in
   the command line).  Something went wrong with the symbol reading and
GDB
   did a longjump in some uncaught situation (I thought we got rid of
those
   though).  Please try opening GDB without specifying a file.

If nothing of the above works, you can try deleting your ~/.gdbtkinit,
rebuilding the whole tree from scratch (something went wrong with
"configure"?),
changing the compiler version etc.  It just works.

If you are still having problems feel free to send me an e-mail.

Good luck,
Fernando



>     can't read "_status": no such variable
>         while executing
>     "$_status configure -text $saved_msg"
>         (object "::.srcwin0.srcwin" method "::SrcWin::set_status" body line 10)
>         invoked from within
>     "set_status $message"
>         (object "::.srcwin0.srcwin" method "::SrcWin::set_execution_status" body line 69)
>         invoked from within
>     "set_execution_status $line $addr"
>         (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 12)
>         invoked from within
>     "$src location BROWSE_TAG [list $linespec]"
>         (procedure "::SrcWin::point_to_main" body line 9)
>         invoked from within
>     "SrcWin::point_to_main"
>         (procedure "gdbtk_tcl_preloop" line 13)
>         invoked from within
>     "gdbtk_tcl_preloop"
>     (gdb)
> 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fnasser@redhat.com Tue Jan 09 03:41:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gdb@sources.redhat.com, Insight List <insight@sources.redhat.com>
Subject: Re: shared libraries in tcl/tk parts of insight
Date: Tue, 09 Jan 2001 03:41:00 -0000
Message-id: <3A5AF877.2B93F0EF@redhat.com>
References: <20010109001927.A600@disaster.jaj.com>
X-SW-Source: 2001-01/msg00023.html
Content-length: 8313

Thanks Phil.  Your patch will be very useful as a reference to get this
fixed.

This things work better with Libtool though.

Fernando

Phil Edwards wrote:
> 
> Okay, last bug report for a few days, I promise.  :-)  I take it that
> --enable-shared isn't a common configuration for Insight?  (I tried naming
> specific tools and libraries in the --enable-shared= argument, but that
> doesn't work like I thought it did.)
> 
> While trying to build a unified gcc+gdb+binutils tree on i686-pc-linux-gnu:
> 
>     rm -f libitcl3.0.so
>     gcc -shared -o libitcl3.0.so itcl_bicmds.o itcl_class.o itcl_cmds.o
>      itcl_ensemble.o itcl_linkage.o itcl_methods.o itcl_migrate.o itcl_objects.o
>      itcl_obsolete.o itcl_parse.o itcl_util.o
>     ranlib libitcl3.0.so
>     ranlib: libitcl3.0.so: File format not recognized
>     gmake[2]: *** [libitcl3.0.so] Error 1
>     gmake[2]: Leaving directory `/home/pme/build/build-2001-01-08/itcl/itcl/unix'
>     gmake[1]: *** [all] Error 1
>     gmake[1]: Leaving directory `/home/pme/build/build-2001-01-08/itcl'
>     gmake: *** [all-itcl] Error 2
> 
> This occurs when --enable-shared was passed to the top-level configure.
> The libraries are being built correctly, but the various Makefile's blindly
> call ranlib on them after the build, and then they will try to do so again
> during installation.
> 
> This happens in a number of tcl/tix/tk/itcl places.  Sometimes the Makefiles
> have rules to correctly call ranlib or not during the build, but do it
> again anyhow during the installation.  There are correct "RANLIB = :"
> definitions created, but they are overridden by the top-level make.
> 
> This patch gets me through things corectly.  It isn't suitable for
> application (it makes assumptions about filename endings), but at least
> points out where the problems occur.
> 
> Also, there are issues with calling the newly-built tclsh during install.
> With --enable-shared LD_LIBRARY_PATH must be used (or libtool!).
> Also, TCL_BIN_DIR wasn't being replaced by configure, and would remain
> @TCL_BIN_DIR@ in the Makefile.  I touch'ed, I autoconf'ed, I grep'ed;
> it just would not be looked at by config.status.  Using any name other
> than TCL_BIN_DIR worked fine.  I don't know why.
> 
> Phil
> [not subscribed to this list]
> 
> Index: itcl/itcl/unix/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/itcl/itcl/unix/Makefile.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 Makefile.in
> --- Makefile.in 2000/02/07 00:19:46     1.1.1.1
> +++ Makefile.in 2001/01/09 04:39:32
> @@ -193,7 +193,7 @@
>  @ITCL_LIB_FILE@:  $(OBJS)
>         rm -f $(ITCL_LIB_FILE)
>         @MAKE_LIB@
> -       $(RANLIB) $(ITCL_LIB_FILE)
> +       case $(ITCL_LIB_FILE) in *.a) $(RANLIB) $(ITCL_LIB_FILE) ;; esac
> 
>  itclsh: tclAppInit.o $(ITCL_LIB_FILE) @TCL_LIB_FULL_PATH@
>         $(CC) @LD_FLAGS@ tclAppInit.o @ITCL_BUILD_LIB_SPEC@ \
> @@ -213,7 +213,7 @@
>         @$(MKINSTALLDIRS) $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR)
>         @echo "Installing $(ITCL_LIB_FILE)"
>         @$(INSTALL_DATA) $(ITCL_LIB_FILE) $(LIB_INSTALL_DIR)/$(ITCL_LIB_FILE)
> -       @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITCL_LIB_FILE))
> +       @case $(ITCL_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITCL_LIB_FILE));; esac
>         chmod 555 $(LIB_INSTALL_DIR)/$(ITCL_LIB_FILE)
>         @echo "Installing itclsh"
>         $(INSTALL_PROGRAM) itclsh $(BIN_INSTALL_DIR)/itclsh$(VERSION)
> Index: itcl/itk/unix/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/itcl/itk/unix/Makefile.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 Makefile.in
> --- Makefile.in 2000/02/07 00:19:46     1.1.1.1
> +++ Makefile.in 2001/01/09 04:39:32
> @@ -226,7 +226,7 @@
>  @ITK_LIB_FILE@: ${OBJS}
>         rm -f $(ITK_LIB_FILE)
>         @MAKE_LIB@
> -       $(RANLIB) $(ITK_LIB_FILE)
> +       case $(ITK_LIB_FILE) in *.a) $(RANLIB) $(ITK_LIB_FILE) ;; esac
> 
>  itkwish: tkAppInit.o $(ITK_LIB_FILE) @TCL_LIB_FULL_PATH@ @TK_LIB_FULL_PATH@ \
>                 @ITCL_LIB_FULL_PATH@
> @@ -253,7 +253,7 @@
>         @$(MKINSTALLDIRS) $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR)
>         @echo "Installing $(ITK_LIB_FILE)"
>         @$(INSTALL_DATA) $(ITK_LIB_FILE) $(LIB_INSTALL_DIR)
> -       @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITK_LIB_FILE))
> +       @case $(ITK_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITK_LIB_FILE));; esac
>         @chmod 555 $(LIB_INSTALL_DIR)/$(ITK_LIB_FILE)
>         @echo "Installing itkwish"
>         $(INSTALL_PROGRAM) itkwish $(BIN_INSTALL_DIR)/itkwish$(VERSION)
> Index: tcl/unix/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/tcl/unix/Makefile.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 Makefile.in
> --- Makefile.in 1999/11/09 01:28:44     1.1.1.1
> +++ Makefile.in 2001/01/09 04:39:38
> @@ -449,7 +449,7 @@
>             done;
>         @echo "Installing $(TCL_LIB_FILE)"
>         @$(INSTALL_DATA) $(TCL_LIB_FILE) $(LIB_INSTALL_DIR)/$(TCL_LIB_FILE)
> -       @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(TCL_LIB_FILE))
> +       @case $(TCL_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(TCL_LIB_FILE));; esac
>         @chmod 555 $(LIB_INSTALL_DIR)/$(TCL_LIB_FILE)
>         @echo "Installing tclsh"
>         @$(INSTALL_PROGRAM) tclsh $(BIN_INSTALL_DIR)/tclsh
> Index: tix/unix/tk8.0/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/tix/unix/tk8.0/Makefile.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 Makefile.in
> --- Makefile.in 2000/02/07 00:19:29     1.1.1.1
> +++ Makefile.in 2001/01/09 04:39:39
> @@ -67,7 +67,7 @@
>  #
>  TCL_SRC_DIR     = @TCL_SRC_DIR@
>  TCL_GENERIC_DIR = $(TCL_SRC_DIR)/generic
> -TCL_BIN_DIR    = @TCL_BIN_DIR@
> +TCL_BIN_DIR = @TCLBINDIR_VARIABLE@
> 
>  # Location of the Tk 8.0 source directory.
>  #
> @@ -84,6 +84,7 @@
> 
>  RUN_TCLSH      = TCL_LIBRARY=$(TCL_SRC_DIR)/library \
>                   TK_LIBRARY=$(TK_SRC_DIR)/library \
> +                 LD_LIBRARY_PATH=$(TCL_BIN_DIR):${LD_LIBRARY_PATH} \
>                   $(TCL_BIN_DIR)/tclsh
> 
> 
> Index: tix/unix/tk8.0/configure.in
> ===================================================================
> RCS file: /cvs/src/src/tix/unix/tk8.0/configure.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 configure.in
> --- configure.in        2000/02/07 00:19:29     1.1.1.1
> +++ configure.in        2001/01/09 04:39:40
> @@ -144,7 +144,7 @@
> 
>  # CYGNUS LOCAL: This used to get TCL_BIN_DIR from TCL_SRC_DIR, which
>  # only works when srcdir == objdir
> -TCL_BIN_DIR=../../../tcl/unix
> +TCLBINDIR_VARIABLE=../../../tcl/unix
> 
>  #--------------------------------------------------------------------
>  #      See if there was a command-line option for where Tk is;  if
> @@ -221,7 +221,7 @@
>  #      Makefile.
>  #--------------------------------------------------------------------
> 
> -file=$TCL_BIN_DIR/tclConfig.sh
> +file=$TCLBINDIR_VARIABLE/tclConfig.sh
>  . $file
>  CC=$TCL_CC
>  SHLIB_CFLAGS=$TCL_SHLIB_CFLAGS
> @@ -387,7 +387,7 @@
>  AC_SUBST(TCL_LIBS)
>  AC_SUBST(TCL_VERSION)
>  AC_SUBST(TCL_SRC_DIR)
> -AC_SUBST(TCL_BIN_DIR)
> +AC_SUBST(TCLBINDIR_VARIABLE)
>  AC_SUBST(TCL_LIB_FULL_PATH)
>  AC_SUBST(TK_BUILD_LIB_SPEC)
>  AC_SUBST(TK_LIBS)
> Index: tk/unix/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/tk/unix/Makefile.in,v
> retrieving revision 1.1.1.1
> diff -u -3 -r1.1.1.1 Makefile.in
> --- Makefile.in 2000/02/07 00:19:30     1.1.1.1
> +++ Makefile.in 2001/01/09 04:39:41
> @@ -386,7 +386,7 @@
>             done;
>         @echo "Installing $(TK_LIB_FILE)"
>         @$(INSTALL_DATA) $(TK_LIB_FILE) $(LIB_INSTALL_DIR)/$(TK_LIB_FILE)
> -       @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(TK_LIB_FILE))
> +       @case $(TK_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(TK_LIB_FILE));; esac
>         @chmod 555 $(LIB_INSTALL_DIR)/$(TK_LIB_FILE)
>         @echo "Installing wish"
>         @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Tue Jan 09 10:34:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: testsuite timeouts
Date: Tue, 09 Jan 2001 10:34:00 -0000
Message-id: <5mr92cwp4x.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00024.html
Content-length: 218

I'm running the GDB testsuite on a pretty slow box --- a 16MHz 68030
--- and getting a lot of failures due to timeouts.  Is there a way 
to increase the timeout value?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Jan 09 11:24:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: Re: testsuite timeouts
Date: Tue, 09 Jan 2001 11:24:00 -0000
Message-id: <5mr92cv8cw.fsf@jtc.redback.com>
References: <5mr92cwp4x.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00025.html
Content-length: 518

>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> I'm running the GDB testsuite on a pretty slow box --- a 16MHz 68030
jtc> --- and getting a lot of failures due to timeouts.  Is there a way 
jtc> to increase the timeout value?

Nevermind.  I found that "set timeout X" at the end of site.exp does
the trick.  

Unfortunately, it appears that the timeouts were caused by some sort
of symbol handling bug which results in a null dereference (and thus
a crash).

        --jtc

-- 
J.T. Conklin
RedBack Networks
From divx@euro.ru Tue Jan 09 14:41:00 2001
From: Eugene Kuznetsov <divx@euro.ru>
To: gdb@sources.redhat.com
Subject: Threading support with glibc 2.2 missing???
Date: Tue, 09 Jan 2001 14:41:00 -0000
Message-id: <361012815.20010109164310@euro.ru>
X-SW-Source: 2001-01/msg00026.html
Content-length: 991

Hello,

      I was using gdb 5.0 with glibc 2.1.2 ( ix86 Linux ) for a long
 time, and it worked pretty well for me. A few days ago I tried
 to upgrade my system to glibc 2.2, which I supposed to be
 stable. Immediately I discovered that I am no longer able to
 debug anything multithreaded at all - command 'info threads' is
 simply ignored, 'thread' shows information only about thread #0, and
 when program crashes with segfault, I am shown the position where it
 was in starting thread.
     I tried compiling sources of gdb from rawhide.redhat.com ( I
 suppose it was CVS snapshot from December 15th ). There things only
 gotten worse ( now even 'thread' does not show any meaningful
 information ).
     What am I doing wrong? Is there anything I can do to get
 debugging of multithreaded programs work again ( except reverting to
 glibc 2.1.2/gdb 5.0, of course )?
     Any help would be greatly appreciated.

-- 
Best regards,
 Eugene                          mailto:divx@euro.ru