Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3A373DC7.A3EC8091@ece.gatech.edu>
Date: Wed, 13 Dec 2000 04:13:43 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: gerrit DOT haase AT t-online DOT de
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: [avail for test] readline-4.1-1
References: <3A341632 DOT 11536 DOT 5F5B80D AT localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Gerrit P. Haase" wrote:
> 
> <3 Dec 2000, 18:25 Uhr wars, als Charles S. Wilson folgendes schrub:>
> < [avail for test] readline-4.1-1 >
> 
> > I've just uploaded readline-4.1-1 to sourceware.  Readline is a library
> > that provides user-input functions complete with history functions and
> > line-editing capabilities.
> 
> Since i installed this readline, i think, i got problems with the shell.
> (STDIN - STOUT), want to say, STDIN is asked, but _before_ STOUT with the
> question is displayed.
> Is it possible, that this behaviour was o.k. since last week?

Installing this readline package can't possibly effect the behavior of
your bash shell.  bash.exe is statically linked, and includes its own
readline implementation.  The libreadline.a/cygreadline4.dll library
can't possibly affect the behavior of ANY pre-existing, statically
linked program.

Now, if you were talking about a customized version of bash that you
personally built, that links to this new readline package (instead of
using bash's own internal readline implementation), then that's a
different story.  But I do not think you did that.

> See also thread 'Perl Module readline'.
> 
> I believe, that CPAN.pm install of perl modules and readline-perl works
> correct before (say last week).

It seems to me that neither Term-ReadLine-Perl-0.9908 nor
TermReadKey-2.14 depend in any way on "libreadline.a".  Each provides
it's own implementation of 'readline-style' functions.  These are the
'readline' packages that are included in the Bundle::CPAN bundle.

So, again, installing the cygwin readline-4.1-X.tar.gz package can't be
the cause of the behavior you describe in that earlier thread.

Note that I am using perl from cygutils (5.6.0), and have installed all
the Bundle::CPAN stuff, including Term-ReadLine-Perl and TermReadKey. 
It all works fine.

-------------

Aside #1:  There also exists a package called
"Term-Readline-Gnu-1.09.tar.gz" that DOES depend on the GNU Readline
library, but it isn't widely used.  Besides, in your earlier thread, you
refer specifically to the term-readline-perl module, which does NOT
depend on GNU's libreadline.

Term-ReadLine-Gnu only works when you link it statically -- but because
of the peculiarities of the perl module building process, you CANNOT
specify '-DREADLINE_STATIC' and '-DNCURSES_STATIC' as described in
/usr/doc/Cygwin/readline-4.1.README.  (To get around this, I edited my
/usr/include/ncurses_dll.h and /usr/include/readline/readline_dll.h
files to explicitly #define FOO_STATIC).  You also CANNOT specify 'gcc
-static' during the link step.  Perl won't let you. (To get around this,
I renamed /usr/lib/libreadline.dll.a and /usr/lib/libncurses.dll.a --
this forces the linker to use the 'next best choice' -- libreadline.a
and libncurses.a -- which are the static libs.  Finally, I also had to
rename /usr/lib/libtermcap.a because I wanted perl to use
readline/ncurses, not readline/termcap.

Then I un-did all those changes after I successfully built
Term-ReadLine-Gnu.

Whew.

The reason the module doesn't work with the dll is this little bit of
code:

static struct str_vars {
  char **var;
  int accessed;
  int read_only;
} str_tbl[] = {
  /* When you change length of rl_line_buffer, you must call
     rl_extend_line_buffer().  See _rl_store_rl_line_buffer() */
  { &rl_line_buffer,                            0, 0 }, /* 0 */
  { &rl_prompt,                                 0, 1 }, /* 1 */
...

And other snippets like it. This leads to lots of errors like this:

Gnu.xs:160: initializer element is not constant
Gnu.xs:160: (near initialization for `str_tbl[0].var')

Basically, the module builds a static database of all global static
variables exposed in the readline library.  For static libs, you can
directly access these globals vars.  You can statically initialize an
array with their addresses.  You can't do that with exported DATA
objects in a dll.  You probably need to code an initialization routine
that 'fills in' these addresses during perl-module-load time.  Since
perl itself is dynamically linked, it builds all externall modules as
dlls -- so this initialization stuff should go into custom dll-init
code, which complicates things even further.  Yuck.

However, when you build this module statically, it works like a charm
(with cygutils perl-5.6.0 on my machine...)

-------------

Aside #2: note that I had to install many of the components manually,
without using the cpan shell: this is because the cpan shell quits when
confronted with an error message from tar.exe.  Unfortunately, tar.exe
generates error messages when the downloaded perl module tarball is
packed thusly:

drwxrwxrwx 0/0               0 2000-05-20 01:18
Term-ReadLine-Perl-0.9908/
  <<< BAD >>>

drwxr-xr-x kjahds/users      0 1999-03-29 11:16 TermReadKey-2.14/
  <<< GOOD >>>

The difference being the USER/GROUP ownership within the tarball -- I'm
*NOT* running as Administrator/Root.
End Aside****)


Just remember that not EVERYTHING that has the letters 'readline' in it,
actually depends on the GNU package called 'readline'.  And not every
wacky STDIO misbehavior in pre-existing programs is caused by the
installation of a new and unrelated package.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com