On Fri, 5 Sep 2008, Dennis Heuer wrote:
> There seems to be a simple linking problem:
>
> /bin/sh ./libtool --tag=CC --mode=link gcc -O2 -o dftables
> dftables.o -lz -lbz2 -lreadline gcc -O2 -o dftables dftables.o -lz
> -lbz2 -lreadline /usr/lib/libreadline.so: undefined reference to
> `tgetnum' /usr/lib/libreadline.so: undefined reference to `tgoto'
> /usr/lib/libreadline.so: undefined reference to `tgetflag'
> /usr/lib/libreadline.so: undefined reference to `BC'
> /usr/lib/libreadline.so: undefined reference to `tputs'
> /usr/lib/libreadline.so: undefined reference to `PC'
> /usr/lib/libreadline.so: undefined reference to `tgetent'
> /usr/lib/libreadline.so: undefined reference to `UP'
> /usr/lib/libreadline.so: undefined reference to `tgetstr'
> collect2: ld returned 1 exit status
From the README file (note the second paragraph):
. It is possible to compile pcretest so that it links with the libreadline
library, by specifying
--enable-pcretest-libreadline
If this is done, when pcretest's input is from a terminal, it reads it using
the readline() function. This provides line-editing and history facilities.
Note that libreadline is GPL-licenced, so if you distribute a binary of
pcretest linked in this way, there may be licensing issues.
Setting this option causes the -lreadline option to be added to the pcretest
build. In many operating environments with a sytem-installed readline
library this is sufficient. However, in some environments (e.g. if an
unmodified distribution version of readline is in use), it may be necessary
to specify something like LIBS="-lncurses" as well. This is because, to quote
the readline INSTALL, "Readline uses the termcap functions, but does not link
with the termcap or curses library itself, allowing applications which link
with readline the to choose an appropriate library."
Philip
--
Philip Hazel
