[GRASS-user] readline issues

[Gerald Nelson]

Sounds like it is not worth the trouble to figure out. In case its useful, here's what appears to be the relevant part of config.log.

configure:7220: checking for location of Readline library
configure:7245: checking for readline in -lreadline
configure:7262: gcc -o conftest -g -O2     -Wl,--export-dynamic conftest.c -lreadline   1>&5
/usr/local/lib/libreadline.so: undefined reference to `tgetnum'
/usr/local/lib/libreadline.so: undefined reference to `tgoto'
/usr/local/lib/libreadline.so: undefined reference to `tgetflag'
/usr/local/lib/libreadline.so: undefined reference to `BC'
/usr/local/lib/libreadline.so: undefined reference to `tputs'
/usr/local/lib/libreadline.so: undefined reference to `PC'
/usr/local/lib/libreadline.so: undefined reference to `tgetent'
/usr/local/lib/libreadline.so: undefined reference to `UP'
/usr/local/lib/libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
configure: failed program was:
#line 7251 "configure"
#include "confdefs.h"

Jerry

---- Original message ----
>Date: Tue, 19 Dec 2006 23:06:39 +0000
>From: Glynn Clements <glynn at gclements.plus.com>  
>Subject: Re: [GRASS-user] readline issues  
>To: "Jerry Nelson" <gnelson at uiuc.edu>
>Cc: <grassuser at grass.itc.it>
>
>
>Jerry Nelson wrote:
>
>> I've been commenting the with-readline=yes option out of my grass6.3
>> configure command (run on a CentOS/Redhat distro) because it can't seem to
>> find the library, even though I have told it where it is. But my question is
>> whether and why this is necessary. My understanding is that readline is what
>> makes command completion possible (in the shell, type a letter and readline
>> will try to complete the word for you). It may also be what makes it
>> possible to use the up and down keys to scroll through previous commands. In
>> the grass command window, I can get previous commands, but I don't get
>> command completion. I tried downloading the grass addon grass-complete but
>> was told my bash was too new for it.
>>  
>> Any suggestions appreciated!
>
>The only part of GRASS which uses readline is r.mapcalc. If readline
>is enabled, you can use its history/editing facilities when entering
>r.mapcalc expressions on stdin.
>
>The GRASS shell is just your normal shell (e.g. bash) with a few
>environment variables set. Command completion should work for GRASS
>commands as with other commands. ISTR that grass-complete adds more
>specific functionality (completing map names?).
>
>Problems with the configure script not "finding" the readline library
>are invariably because it requires one of the terminal libraries
>(libtermcap, libtinfo or lib[n]curses) but doesn't list the library as
>a dependency.
>
>Consequently, when configure tries to link a test program (which is
>how it checks for libraries) against readline, it fails due to
>unresolved symbols (typically tgetent, tgetstr etc). You can confirm
>this by examining the end of the config.log file.
>
>Normally, we would just add a list of optional libraries to the
>configure check, so that it first tests readline alone, then tests
>readline + libtermcap/libtinfo/lib[n]curses. E.g. for TIFF, in
>addition to libtiff, it also tries all possible combinations of the
>JPEG, zlib and math libraries until either one combination succeeds or
>all eight combinations have failed.
>
>The problem here is that there are at least three common libraries
>(counting libcurses/libncurses as one library) which may all provide
>the same set of functions (the "termcap" API: tgetent() etc), and
>there is no obvious "right" choice. It's quite possible that multiple
>options will succeed, at least in terms of linking.
>
>However, using different libraries may produce different results. E.g. 
>one library might use the termcap database while another uses the
>terminfo database; some libraries might honour the TERMCAP and/or
>TERMINFO environment variables, some might not.
>
>If we pick the wrong one, the configure test will succeed but any
>program which uses it might not actually run. As r.mapcalc is a
>critical module (a lot of scripts use it internally), ensuring that it
>works has a higher priority than enabling interactive line editing.
>
>-- 
>Glynn Clements <glynn at gclements.plus.com>
Gerald Nelson
Professor, Dept. of Agricultural and Consumer Economics
University of Illinois, Urbana-Champaign
office: 217-333-6465 
cell: 217-390-7888
315 Mumford Hall
1301 W. Gregory
Urbana, IL 61801