Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: fwd:  fixing some FIXMEs
       [not found] <20010108210432.A32378@disaster.jaj.com>
@ 2001-01-08 17:59 ` Christopher Faylor
  2001-01-09  0:29 ` Eli Zaretskii
  1 sibling, 0 replies; 2+ messages in thread
From: Christopher Faylor @ 2001-01-08 17:59 UTC (permalink / raw)
  To: gdb

On Mon, Jan 08, 2001 at 09:04:32PM -0500, Phil Edwards wrote:
>
>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?  This would need to be committed in both the src and
>gcc repositories, I believe, but since the patch deals with GDB/Insight,
>it was suggested that it be hashed over here first.

The changes make sense to me, except for the "Moved from configure"
comment.  That will just be puzzling to someone who stumbles across it,
I think.

cgf

>
>Index: configure
>===================================================================
>RCS file: /cvs/gcc/gcc/configure,v
>retrieving revision 1.33
>diff -u -3 -r1.33 configure
>--- configure	2001/01/02 15:44:40	1.33
>+++ configure	2001/01/09 00:21:16
>@@ -1069,21 +1069,6 @@
> export CFLAGS
> export CXXFLAGS
> 
>-# FIXME: This should be in configure.in, not configure
>-case "$host" in
>-	*go32*)
>-	    enable_gdbtk=no ;;
>-	*msdosdjgpp*)
>-	    enable_gdbtk=no ;;
>-esac
>-
>-# FIXME: This should be in configure.in, not configure
>-# Determine whether gdb needs tk/tcl or not.
>-if [ "$enable_gdbtk" != "no" ]; then
>-	GDB_TK="all-tcl all-tk all-itcl all-tix all-libgui"
>-else
>-	GDB_TK=""
>-fi
> 
> for subdir in . ${subdirs} ; do
> 
>Index: configure.in
>===================================================================
>RCS file: /cvs/gcc/gcc/configure.in,v
>retrieving revision 1.84
>diff -u -3 -r1.84 configure.in
>--- configure.in	2001/01/02 15:36:25	1.84
>+++ configure.in	2001/01/09 00:21:16
>@@ -277,6 +277,14 @@
>   fi
> fi
> 
>+# Moved from configure.
>+case "$host" in
>+  *go32*)
>+    enable_gdbtk=no ;;
>+  *msdosdjgpp*)
>+    enable_gdbtk=no ;;
>+esac
>+
> # We default to --with-shared on platforms where -fpic is meaningless.
> # Well, we don't yet, but we will.
> if false && [ "${host}" = "${target}" ] && [ x${enable_shared} = x ]; then
>@@ -974,6 +982,14 @@
>   use_gnu_as=no
>   noconfigdirs="$noconfigdirs gas"
> fi
>+
>+# Determine whether gdb needs tk/tcl or not.  Moved from configure.
>+if [ "$enable_gdbtk" != "no" ]; then
>+  GDB_TK="all-tcl all-tk all-itcl all-tix all-libgui"
>+else
>+  GDB_TK=""
>+fi
>+
> 
> # Figure out what language subdirectories are present.
> # Look if the user specified --enable-languages="..."; if not, use
>

-- 
cgf@cygnus.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/
From pedwards@disaster.jaj.com Mon Jan 08 20:31:00 2001
From: Phil Edwards <pedwards@disaster.jaj.com>
To: gdb@sources.redhat.com
Subject: _status: no such variable
Date: Mon, 08 Jan 2001 20:31:00 -0000
Message-id: <20010108234026.A450@disaster.jaj.com>
X-SW-Source: 2001-01/msg00018.html
Content-length: 1104

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

    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) 


-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.
From pedwards@disaster.jaj.com Mon Jan 08 20:32:00 2001
From: Phil Edwards <pedwards@disaster.jaj.com>
To: gdb@sources.redhat.com
Subject: Re: fwd: fixing some FIXMEs
Date: Mon, 08 Jan 2001 20:32:00 -0000
Message-id: <20010108234221.A467@disaster.jaj.com>
X-SW-Source: 2001-01/msg00019.html
Content-length: 581

[I'm not subscribed to gdb; please cc me on replies.]


> The changes make sense to me, except for the "Moved from configure"
> comment.  That will just be puzzling to someone who stumbles across it,
> I think.

Yeah, that's a placeholder for some more meaningful comment.  "These hosts
can't build this software" is all I know to put there, though.


-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.
From pedwards@disaster.jaj.com Mon Jan 08 21:09:00 2001
From: Phil Edwards <pedwards@disaster.jaj.com>
To: gdb@sources.redhat.com
Subject: shared libraries in tcl/tk parts of insight
Date: Mon, 08 Jan 2001 21:09:00 -0000
Message-id: <20010109001927.A600@disaster.jaj.com>
X-SW-Source: 2001-01/msg00020.html
Content-length: 7307

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: fwd:  fixing some FIXMEs
       [not found] <20010108210432.A32378@disaster.jaj.com>
  2001-01-08 17:59 ` fwd: fixing some FIXMEs Christopher Faylor
@ 2001-01-09  0:29 ` Eli Zaretskii
  1 sibling, 0 replies; 2+ messages in thread
From: Eli Zaretskii @ 2001-01-09  0:29 UTC (permalink / raw)
  To: pedwards; +Cc: gdb

> 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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-01-09  0:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20010108210432.A32378@disaster.jaj.com>
2001-01-08 17:59 ` fwd: fixing some FIXMEs Christopher Faylor
2001-01-09  0:29 ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox