------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=997
Philip Hazel <ph10@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Philip Hazel <ph10@???> 2010-06-08 12:21:11 ---
This is documented in the README file:
--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." If you get error
messages about missing functions tgetstr, tgetent, tputs, tgetflag, or tgoto,
this is the problem, and linking with the ncurses library should fix it.
There is no need to hand-edit. I have closed this as INVALID because I have no
idea of how one might get configure to determine whether libreadline is
"entire" or whether it needs another library - and if it does, whether it
should be curses or something else. On my Linux, for example (Gentoo), there is
no need for -lcurses; the system install of readline handles it.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
