From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail.clark.net ([168.143.0.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24664>; Tue, 12 Aug 1997 18:06:25 -0400
Received: from clark.net (root@explorer.clark.net [168.143.0.7]) by mail.clark.net (8.8.5/8.6.5) with ESMTP id RAA11927; Tue, 12 Aug 1997 17:55:48 -0400 (EDT)
Received: from clark.net (culliton@localhost [127.0.0.1]) by clark.net (8.8.5/8.7.1) with ESMTP id RAA15689; Tue, 12 Aug 1997 17:55:47 -0400 (EDT)
Message-Id: <199708122155.RAA15689@clark.net>
To:	Paul Haahr <haahr@netcom.com>
cc:	Tom Culliton <culliton@clark.net>,
	Russell Davies <c9415019@cs.newcastle.edu.au>,
	rc@hawkwind.utcs.toronto.edu, culliton@clark.net
Subject: Re: rc,linux,signal,readline 
In-reply-to: Your message of "Tue, 12 Aug 1997 14:24:34 PDT."
             <8PZdii2+2@localhost.localdomain.netcom.com> 
Date:	Tue, 12 Aug 1997 17:55:46 -0400
From:	Tom Culliton <culliton@clark.net>

On Tue, 12 Aug 1997 14:24:34 PDT, Paul Haahr wrote:
> > >  	I have been trying for a while now to get the following 
> > >  	working under linux..without success..
> > >  
> > >  	a _dynamically linked_ rc shell with;
> > 
> > I have sent patches to the list which take care of all the rest of
> > your requests, but for some reason the shared/dynamic version of GNU
> > readline doesn't work like the static version.  At least thats my
> > first guess as to the problem.  Without readline it works "properly"
> > and trips clean when linked dynamically.  With readline it doesn't.
> 
> Could it be that you're getting the wrong readline.so?  There were real
> changes between the 1.x and 2.x versions, as I remember.

Not as far as I could tell.  There are no rcs ident strings in the
libraries (Hey, Chet!) but the libs are:

-rw-r--r--   1 root     root       154214 Aug 19  1996 /usr/lib/libreadline.a
-rw-r--r--   1 root     root       132113 Aug 19  1996 /usr/lib/libreadline.so.2.0

and look pretty much the same via nm.  I spent quite a bit of time on
this but not being an expert on dynamic linking didn't dig too deep.

BTW - does anyone know why on DEC Alpha OSF1, using the libreadline
from the freeware CD, it dumps core when I hit ^R?  The trace back
looks like this:

(gdb) core core
Core was generated by `rc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/shlib/libc.so...done.
#0  0x3ff800d1870 in strlen ()
(gdb) where
#0  0x3ff800d1870 in strlen ()
#1  0x3ff800d94f0 in _doprnt ()
#2  0x3ff800d5538 in sprintf ()
#3  0x120034da4 in rl_message (format=0x14000a830 "%s", arg1=1073818992,
    arg2=0) at display.c:669
#4  0x120035a20 in rl_display_search (search_string=0x140015d00 "",
    reverse_p=1, where=-1) at isearch.c:106
#5  0x120035c8c in rl_search_history (direction=-1, invoking_key=18)
    at isearch.c:193
#6  0x1200358a0 in rl_reverse_search_history (sign=1, key=18) at isearch.c:61
#7  0x120020970 in rl_dispatch (key=18, map=0x140000fb0) at readline.c:636
#8  0x12002007c in readline_internal () at readline.c:345
#9  0x12001fe80 in readline (prompt=0x140012c80 "[culliton@cns5]rc-1.5tjc/ : ")
    at readline.c:268
#10 0x120016f18 in ugchar ()
#11 0x120016fe4 in ugchar ()
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0xa79d9180f43ffffd
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable).  In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.


Pretty cool, huh? ;-)