For RHEL 3 (and it also appears RHEL 4 and 5) the libreadline shared lib
has no specified lib requirement that satisfies the tgetent and related
symbols. (These symbols are provided by ncursesw, ncurses, curses,
termcap as noted in the python setup.py.) The configure script does not
add these required libs in for the readline tests, and so the autoconf
tests will fail and it will incorrectly determine that readline is not
present (and so not define HAVE_RL_COMPLETION_MATCHES etc.)

I guess this generally does not prevent the readline module from being
compiled since setup.py does its own search for readline and adds in the
needed curses library. It does prevent proper declaration of the
completion_matches function, however. On 32 bit systems this doesn't
matter but on 64 bit ones it does as the undeclared (but present in
libreadline) completion_matches returns a char **.

The fix checked in with r54874 after the 2.5.1 release (issue 1703270)
to Modules/readline.c fixes the problem for completion_matches
specifically, but the problem of incorrect determination of readline
presence still exists.

Attached is a patch to fix the problem: it adds the necessary additional
library to the temporary LIBS definition in the readline tests, using
the same order of curses libs specified in setup.py. (The patch includes
the  changes for the configure script in addition to configure.in.)

Urgh. Re-reading this, I could barely understand what the hell I was saying.

The problem: 64 bit compiles will dump core when readline is used if
they don't properly identify the presence of readline and use the system
headers.

The solution: fix autoconf to properly recognize when readline is
present by providing configure's readline test program with all
necessary prerequisites.

caveat: The fix for issue 1703270 (already checked in post-2.5.1) works
around this by hard coding the completion_matches prototype in
Modules/readline.c, but the autoconf fix seems better long term.

The patch looks reasonable.  I'll commit it on Monday when I'm on a
machine with a more up-to-date autoconf.

In the configure{.in} exist another bug:
--------------
AC_CHECK_LIB(readline, readline)
if test "$ac_cv_have_readline_readline" = no
then
  AC_CHECK_LIB(termcap, readline)
fi
--------------
but "grep _readline_readline configure" show that variable in use is
$ac_cv_lib_readline_readline, so the check for function termcap in
readline can be removed safely - it is never reached.

I would like to propose another patch that don't use possible unresolved
symbol to detect presence of library. The new patch will define
HAVE_LIBREADLINE. If necessary will check for dependent library
and link it in correct order. The script print messages like next:
------
checking how to link readline libs... -lreadline -lncursesw
checking for rl_callback_handler_install in -lreadline... yes
checking for rl_pre_input_hook in -lreadline... yes
checking for rl_completion_matches in -lreadline... yes
------

The patch is for branch release25-maint.
It is without changes in configure script, i.e autoconf has to run to
recreate it after applying.
The patch can be applied to trunk as well.

when committing this one, the platform specific openbsd/amd64 fix I
committed for this in issue 3645 should probably be verified as unneeded
and undone.

marking as release blocker as we should make sure this autoconf update
goes in before the 2.6/3.0 release.  compiling for 64bit with readline
should work out of the box withing requiring patches on the most common
OSes.

I'm verifying rpetrov's patch in my centos4 VM now...

I've attached an updated patch.  Not much changed other than the better
diff -u format, a couple grammar errors in comments and inclusion of the
new autoconf generated configure script.

It works fine for me on ubuntu hardy 32bit, CentOS 5.x x86_64, MacOS X
10.5 32-bit and 64-bit.

Could someone confirm on a platform where linking with 64bit readline
was broken before that this fixes it.  I added Henry Precheur to the
nosy list as he should be able to confirm on OpenBSD/amd64.

Lowering this to deferred blocker as it need not hold up -rc1 so long as
we get it in before -rc2.

According to config.log the readline functions are correctly detected. I
tested the patch with Python 2.5 & 2.6 and both work with the test I
posted on issue 3645.

fixed in trunk r66283 (followed by rerunning autoconf to generate a new
configure script in r66284).

merged into py3k branch in r66285.

backported to release25-maint in r66288 and r66289.

I realize too late that in my patch line "if test $py_cv_lib_readline =
!yes; then" is not correct. :(
It has to be "if test $py_cv_lib_readline = no; then", i.e. s/!yes/no/'.

eek.  not quite fixed then :)

i'll retest and take care of it.

fixed in trunk r66295/r66296.

merging and backporting now...

merged to py3k r66297 + r66298

backported to release25-maint r66299 + r66300.