Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release

[patl@cag.lcs.mit.edu (Patrick J. LoPresti)]

Andrew Cagney <ac131313@cygnus.com> writes:

> With that said, I would consider a one month gap between 5.0 and 5.1 to
> be unrealistic. I'd also consider it un-reasonable to mandate the
> acceptance of patches just because a reasonable solution isn't
> available.

I think it depends on the situation.  At this point, stock GDB has
been broken on Linux/x86 for several *years*.

The problem with debugging across dlopen()/dlclose()/dlopen() sounds
complicated.  It is also fairly obscure.  However, being unable to use
breakpoints in *any shared library at all* is not obscure.  It makes
stock GDB extremely painful for a lot of uses.  If GDB 5.0 is released
with the same problem, I suspect the word among Linux developers will
be the same as it has been for the last few years: "Stock GDB is
broken; don't use it."

The SamL/H.J. patches fix the problem, as far as we can tell here.
And those patches are not very large.  Is it really so hard to put
them in and fix the problem the Right Way later?  The argument "we
can't accept every hack" is pretty weak.  You are not being asked to
accept every hack, you are being asked to accept a single hack which
addresses a very serious problem on a major platform.

Just $0.02 from a developer who is tired of manually patching
prereleases...

 - Pat
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: COERCE_FLOAT_TO_DOUBLE
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050836.DAA10166@indy.delorie.com>
X-SW-Source: 2000-q1/msg00543.html
Content-length: 428

The comments about COERCE_FLOAT_TO_DOUBLE in valops.c seem to suggest
that every modern architecture should define it to
standard_coerce_float_to_double.  I was about to add that definition
to tm-go32.h when I noticed that none of the other i386 targets,
including linux native, does that--they all use the default
definition.

Shouldn't most/all i386 targets, at least those which use GCC, use
standard_coerce_float_to_double?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Love <lha@stacken.kth.se>
Cc: gdb@sourceware.cygnus.com, assar@sics.se
Subject: Re: backtrace from random $fp $pc
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4F543.58AF8D8E@cygnus.com>
References: <amvh5xpigc.fsf@hummel.e.kth.se>
X-SW-Source: 2000-q1/msg00238.html
Content-length: 2647

Love wrote:
> 
> In a project I'm writing on we have a custom thread package. It
> context-switches on select and do stack mangling when.
> 
> Now there is to way to do backtrace:ing on diffrent threads.
> 
> I have a patch (on 4.18) that enable us to do that
> < http://www.stacken.kth.se/projekt/arla/gdb-4.18-backfrom.diff > by
> choosning the right $fp and $sp. Se below for example (the exemple uses
> wrong $pc). As you see I use a sequence to find fp/pc.

The thing to do is study how one of the *thread* modules have been
implemented.  If you can teach GDB how to find the per thread
information then it can automatically handle the threads.

> Now that question is, how should thread support really work for random
> thread-packages ? We have the idea that the thread package would provide a
> magic variable to a function that gdb sets and the thead package call each
> time it does a thread-releated operation that gdb needs to know.

At present, GDB is largely passive.  It lets the target run.  When the
target stops GDB is told, among other things, ``hey this is a new
thread''.  GDB then typically lets the target run again.
(The thread experts can ROTFL at this description :-)

> A many related question: What is tfind, since that seam to be releated to
> backtrace:ing (but on remote targets ?) would that be possible to use for
> the same things that my patch does ?

Without reading the manual/source, I don't know.

For the backtrace command, in theory, it is possible to set ``$fp'' and
as a side effect change the stack that GDB is displaying.  ($fp is not
what the VAX hackers might think - it's a badly named gdb internal
variable that provides a handle onto the frame.  It may or may not
correspond to a real register).

	enjoy,
		Andrew

> 
> Love
> 
> (gdb) lwp_ps
> Runnable[0]
>  name: IO MANAGER
>   eventlist:
>   fp: 0x806aac4
>   pc: 0x806aac4
>  name: producer
>   eventlist: 8048b00
>   fp: 0x8083b40
>   pc: 0x8083b40
> Runnable[1]
> [...]
> (gdb) help backfrom
> Print backtrace of FRAMEPOINTER and PROGRAMCOUNTER.
> 
> (gdb) backfrom 0x8083b40 0x8083b40
> #0  0x8083b40 in ?? ()
> #1  0x8049e2f in LWP_MwaitProcess (wcount=1, evlist=0x8083b70)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:567
> #2  0x8049eaf in LWP_WaitProcess (event=0x8048b00)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:585
> #3  0x8048b12 in Producer (foo=0x0)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/testlwp.c:76
> #4  0x804a00c in Create_Process_Part2 ()
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:629
> #5  0xfffefdfc in ?? ()
> #6  0x8051980 in ?? ()
From blizzard@mozilla.org Sat Apr 01 00:00:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: gdb@sourceware.cygnus.com
Subject: problems loading shared libraries - with attached test case
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DFD84E.9F330EC1@mozilla.org>
X-SW-Source: 2000-q1/msg00820.html
Content-type: multipart/mixed; boundary="----------=_1583534245-23286-8"

This is a multi-part message in MIME format...

------------=_1583534245-23286-8
Content-length: 4225

Hi, I'm having problems loading shared libraries.  This is with a build
of gdb out of cvs that I pulled and built on March 27th and has been
there for at least a week.  I haven't gone back further than that.  This
is with the gcc that is shipping with Red Hat 6.2:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

I'm using "set auto-solib-add 0" after main has been called.  If I use
"shar" to load a shared library manually once I can't use it again to
load another shared library later.  Please see the attached log for an
example of how to reproduce the problem.

--Chris

GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x8048576: file main.c, line 5.
(gdb) r
Starting program: /home/blizzard/src/gdb_test/main 

Breakpoint 1, main (argc=1, argv=0xbffff9c4) at main.c:5
5         void *handle0 = dlopen("./libdummy0.so", RTLD_LAZY);
(gdb) set auto-solib-add 0
(gdb) n
6         void *handle1 = dlopen("./libdummy1.so", RTLD_LAZY);
(gdb) n
7         void *handle2 = dlopen("./libdummy2.so", RTLD_LAZY);
(gdb) n
8         void *handle3 = dlopen("./libdummy3.so", RTLD_LAZY);
(gdb) n
9         printf("Hi.\n");
(gdb) shar dummy0
Reading symbols from /home/blizzard/src/gdb_test/./libdummy0.so...done.
Loaded symbols for /home/blizzard/src/gdb_test/./libdummy0.so
(gdb) shar dummy1
(gdb) info shar
From        To          Syms Read   Shared Object Library
0x4001a000  0x4001d08c  Yes         /lib/libdl.so.2
0x4001e000  0x4005ff90  Yes         /usr/lib/libstdc++-libc6.1-1.so.2
0x40060000  0x4007c9d8  Yes         /lib/libm.so.6
0x4007d000  0x4017185c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
0x40015000  0x40016cdc  Yes        
/home/blizzard/src/gdb_test/./libdummy0.so
0x40017000  0x40018cdc  No         
/home/blizzard/src/gdb_test/./libdummy1.so
0x40173000  0x40174cdc  No         
/home/blizzard/src/gdb_test/./libdummy2.so
0x40175000  0x40176cdc  No         
/home/blizzard/src/gdb_test/./libdummy3.so
(gdb) shar dummy3
(gdb) shar /home/blizzard/src/gdb_test/./libdummy2.so
(gdb) info shar
From        To          Syms Read   Shared Object Library
0x4001a000  0x4001d08c  Yes         /lib/libdl.so.2
0x4001e000  0x4005ff90  Yes         /usr/lib/libstdc++-libc6.1-1.so.2
0x40060000  0x4007c9d8  Yes         /lib/libm.so.6
0x4007d000  0x4017185c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
0x40015000  0x40016cdc  Yes        
/home/blizzard/src/gdb_test/./libdummy0.so
0x40017000  0x40018cdc  No         
/home/blizzard/src/gdb_test/./libdummy1.so
0x40173000  0x40174cdc  No         
/home/blizzard/src/gdb_test/./libdummy2.so
0x40175000  0x40176cdc  No         
/home/blizzard/src/gdb_test/./libdummy3.so
(gdb) 


-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I bet a funny thing about driving a car off a cliff is, while
you're in midair, you still hit those brakes! Hey, better try
the emergency brake!
------------
CFLAGS = -g

SHLIBS = libdummy0.so libdummy1.so libdummy2.so libdummy3.so
TARGET = main

all: $(SHLIBS) $(TARGET)

main: main.c
	g++ $(CFLAGS) -o main main.c -ldl

libdummy0.cpp: gen_files.pl
	./gen_files.pl dummy0 > libdummy0.cpp

libdummy0.so: libdummy0.cpp
	g++ $(CFLAGS) -o libdummy0.so -shared -fPIC libdummy0.cpp

libdummy1.cpp: gen_files.pl
	./gen_files.pl dummy1 > libdummy1.cpp

libdummy1.so: libdummy1.cpp
	g++ $(CFLAGS) -o libdummy1.so -shared -fPIC libdummy1.cpp

libdummy2.cpp: gen_files.pl
	./gen_files.pl dummy2 > libdummy2.cpp

libdummy2.so: libdummy2.cpp
	g++ $(CFLAGS) -o libdummy2.so -shared -fPIC libdummy2.cpp

libdummy3.cpp: gen_files.pl
	./gen_files.pl dummy3 > libdummy3.cpp

libdummy3.so: libdummy3.cpp
	g++ $(CFLAGS) -o libdummy3.so -shared -fPIC libdummy3.cpp

clean:
	rm -f libdummy*.cpp *.so *.o *~ main

------------=_1583534245-23286-8
Content-Type: text/x-perl; charset=us-ascii; name="gen_files.pl"
Content-Disposition: inline; filename="gen_files.pl"
Content-Transfer-Encoding: base64
Content-Length: 1627

IyEvdXNyL2Jpbi9wZXJsCgokbnVtID0gMTA7CgokcHJlZml4ID0gJEFSR1Zb
MF07CgppZiAoISRwcmVmaXgpIHsKICBkaWUoInVzYWdlOiBnZW5fZmlsZXMu
cGwgPHByZWZpeD5cbiIpOwp9CgpwcmludF9jbGFzc19kZWNsKCk7CnByaW50
X2NsYXNzX3VzZSgpOwojcHJpbnRfbWFpbl9zdGFydCgpOwojcHJpbnRfY2xh
c3NfdXNlKCk7CiNwcmludF9tYWluX2VuZCgpOwoKc3ViIHByaW50X2NsYXNz
X2RlY2wgewogIGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAg
IHByaW50ICgiY2xhc3MgZHVtbXlfIiAuICRpIC4gIl9rbGFzcyB7IHB1Ymxp
YzogaW50IGk7XG4iKTsKICAgIG15ICRqOwogICAgZm9yICgkaiA9ICRpIC0g
MTsgJGogPiAwOyAkai0tKSB7CiAgICAgIHByaW50ICgiZHVtbXlfIiAuICRq
IC4gIl9rbGFzcyBtZW1iZXJfIiAuICRqIC4gIjtcbiIpOwogICAgfQogICAg
cHJpbnQgKCJ9O1xuIik7CiAgfQp9CgpzdWIgcHJpbnRfY2xhc3NfdXNlIHsg
IAogIGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAgIHByaW50
ICgiJHByZWZpeF8iIC4gJGkgLiAiX2tsYXNzICpmb29fIiAuICRpIC4gIjtc
biIpOwogIH0KCiAgZm9yICgkaSA9IDA7ICRpIDwgJG51bTsgJGkrKykgewog
ICAgcHJpbnQgKCJmb29fIiAuICRpIC4gIiA9IG5ldyAiIC4gIiRwcmVmaXhf
IiAuICRpIC4gIl9rbGFzcygpO1xuIik7CiAgfQoKICBmb3IgKCRpID0gMDsg
JGkgPCAkbnVtOyAkaSsrKSB7CiAgICBwcmludCAoImZvb18iIC4gJGkgLiAi
LT5pID0gMjM7XG4iKTsKICB9Cn0KCnN1YiBwcmludF9jbGFzc191c2Ugewog
IGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAgIHByaW50ICgi
dm9pZCAiIC4gJHByZWZpeCAuICJfZnVuY18iIC4gJGkgLiAiKHZvaWQpIHsg
XG4iKTsKICAgIG15ICRqOwogICAgZm9yICgkaiA9IDA7ICRqIDwgJGk7ICRq
KyspIHsKICAgICAgcHJpbnQgKCJkdW1teV8iIC4gJGogLiAiX2tsYXNzIGJh
cl8iIC4gJGogLiAiO1xuIik7CiAgICB9CiAgICBwcmludCAoIn1cbiIpOwog
IH0KfQoKc3ViIHByaW50X21haW5fc3RhcnQgewogIHByaW50ICgiaW50IG1h
aW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KVxuIik7CiAgcHJpbnQgKCJ7XG4i
KTsKfQoKc3ViIHByaW50X21haW5fZW5kIHsKICBwcmludCAoInJldHVybiAw
O1xuIik7CiAgcHJpbnQgKCJ9XG4iKTsKfSAgCg==

------------=_1583534245-23286-8--
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: printing array element broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA5296.E4C28331@cygnus.com>
References: <20000202102302.A29253@visi.com>
X-SW-Source: 2000-q1/msg00307.html
Content-length: 1280

Grant Edwards wrote:
> 
> I've an array of 4 structures named txFrameDescrArray.  When I
> print the entire array, everything is fine:
> 
> (gdb) print/x txFrameDescrArray
> $2 = {{FrameDataPtr = 0x100e10, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105610},
>       {FrameDataPtr = 0x101400, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105620},
>       {FrameDataPtr = 0x1019f0, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105630},
>       {FrameDataPtr = 0x101fe0, Reserved = 0x0, StatusAndFrameLength = 0x0, NextFD = 0x105600}}
> 
> However, asking gdb to print an individual element results in garbage:
> 
> (gdb) print/x txFrameDescrArray[0]
> $3 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
> 
> (gdb) print/x txFrameDescrArray[1]
> $5 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
> 
> What am I doing wrong?

I guess you've compared:

	(gdb) print txFrameDescrArray
with	(gdb) print txFrameDescrArray[0]

and checked that that works ok.

Looking at your output, I suspect that yes, you've found a bug. 
Interested in extending the testsuite to test for this?  Or trying for a
patch?

	Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: GDB <gdb@sourceware.cygnus.com>
Subject: [hercules@lokigames.com: solib patch for gdb 4.17.0.14]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000204124020.C1647@lucon.org>
X-SW-Source: 2000-q1/msg00105.html
Content-length: 2996

----- Forwarded message from Sam Lantinga <hercules@lokigames.com> -----

Delivered-To: hjl@lucon.org
Date: Mon, 31 Jan 2000 17:00:17 -0800
From: Sam Lantinga <hercules@lokigames.com>
Organization: Loki Entertainment Software
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
To: hjl@lucon.org
Cc: coders@lokigames.com, Sam Lantinga <hercules@lokigames.com>
Subject: solib patch for gdb 4.17.0.14


This patch fixes the shared library problem I mailed you about earlier.
This affects any code which dynamically unloads shared objects.  Games
are notorious for this. :)

See ya!
-- 
	-Sam Lantinga, Lead Programmer, Loki Entertainment Software
diff -ruN gdb-4.17/gdb/infrun.c gdb-4.17.new/gdb/infrun.c
--- gdb-4.17/gdb/infrun.c	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/infrun.c	Mon Jan 31 16:39:20 2000
@@ -1192,6 +1192,9 @@
                   CHECK_SOLIB_CONSISTENCY();
 #endif
 		  SOLIB_ADD (NULL, 0, NULL);
+#ifdef UNLOAD_UNUSED_SOLIB
+                  UNLOAD_UNUSED_SOLIB();
+#endif
 	          target_terminal_inferior ();
 		}
 
diff -ruN gdb-4.17/gdb/solib.c gdb-4.17.new/gdb/solib.c
--- gdb-4.17/gdb/solib.c	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/solib.c	Mon Jan 31 16:46:31 2000
@@ -918,6 +918,58 @@
 
 /*
 
+GLOBAL FUNCTION
+
+	unload_unused_solib -- dump symbols from unloaded shared objects
+
+SYNOPSIS
+
+	void unload_unused_solib (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker breakpoint
+	and allows us to unload objects which are no longer valid in the
+	in the inferior.
+
+AUTHOR
+	Sam Lantinga <hercules@lokigames.com>
+ */
+
+void
+unload_unused_solib (void)
+{
+
+#ifdef SVR4_SHARED_LIBS
+
+    struct objfile *current;
+
+    for ( current=symfile_objfile; current; current=current->next ) {
+        struct so_list *so;
+        char *bfd_filename;
+        for ( so=so_list_head; so; so=so->next ) {
+            if (so->abfd) {
+                bfd_filename = bfd_get_filename (so->abfd);
+                if ( bfd_filename ) {
+                    if ( strcmp(bfd_filename, current->name) == 0 ) {
+                        break;
+                    }
+                }
+            }
+        }
+        if ( (current != symfile_objfile) && (so == NULL) ) {
+/*printf("Freeing objfile: %s\n", current->name);*/
+            free_objfile(current);
+            break;
+        }
+    }
+
+#endif	/* SVR4_SHARED_LIBS */
+
+}
+
+/*
+
 LOCAL FUNCTION
 
 	find_solib -- step through list of shared objects
diff -ruN gdb-4.17/gdb/solib.h gdb-4.17.new/gdb/solib.h
--- gdb-4.17/gdb/solib.h	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/solib.h	Mon Jan 31 16:40:14 2000
@@ -59,6 +59,10 @@
 
 #define CHECK_SOLIB_CONSISTENCY()	check_solib_consistency()
 
+/* Brute force check of library consistency */
+
+#define UNLOAD_UNUSED_SOLIB()		unload_unused_solib()
+
 /* If ADDR lies in a shared library, return its name.  */
 
 #define PC_SOLIB(addr)	solib_address (addr)


----- End forwarded message -----
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002072152.QAA06843@devserv.devel.redhat.com>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <200002072132.WAA08489@soliton.wins.uva.nl>
X-SW-Source: 2000-q1/msg00137.html
Content-length: 1061

> And I hope that the patches I sent in the last few months "prove" this
> commitment.

Sending in patches is a great way to show commitment, yes.  Care to
list the patches which have been submitted but not checked in?  URLs
to sourceware.cygnus.com mail archives are sufficient, I'm not asking
for updating or new analysis unless perhaps if you know the old
submission is wrong.  You can see my own list (for patches I have
submitted) at http://people.redhat.com/kingdon/

At the risk of making an inflammatory and/or irrelevant analogy, I
think of it a little bit like TCP/IP.  In TCP, a sender needs to
retransmit if packets are dropped by IP.  Furthermore, in case of
congestion random-drop generally works better than queueing.

> A speedup in evaluation and/or integration of patches would certainly
> be welcome.  There have been suggestions like "write-after-approval"
> access for more people.

As far as I know this is underway (unless of course if everyone is
assuming someone else is taking care of making it happen).  Feel free
to keep bugging us.
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: So who maintains the web pages?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002200454.XAA28897@devserv.devel.redhat.com>
References: <38A60492.2BB9E437@cygnus.com> <bu2jdc2mp.fsf@rtl.cygnus.com> <38ABB2C9.4102933B@cygnus.com>
X-SW-Source: 2000-q1/msg00350.html
Content-length: 262

> FYI, I'm a web section to the maintainers file and you're it!

I'm not sure how to parse that sentence but let me know if you are
asking me to send in suggested changes to MAINTAINERS or anything like
that (there isn't anything there yet about the web pages).
From aoliva@cygnus.com Sat Apr 01 00:00:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: `make check' with --enable-shared
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <ority3q10w.fsf@zecarneiro.lsd.ic.unicamp.br>
X-SW-Source: 2000-q1/msg00845.html
Content-length: 487

When the srcware tree is configured with --enable-shared, the `expect'
program won't run properly.  Jim Wilson found out gdb has a local hack
to set LD_LIBRARY_PATH, but, AFAIK, no other project has been hacked
similarly.

Here's a simple patch that renders that gdb hack obsolete, and
arranges for all packages to automatically benefit from it.  I'm not
reverting the gdb hack, though.  I'll leave that to the gdb hackers
:-)

Here's the patch I'm checking in, approved by Jim Wilson: