Azarah merged readline-4.2 and tested it with python-2.2.1-r1. Python's ./configure tried using -ltermcap instead of -lncurses and died: 15:53 <@Azarah> configure:7289: gcc -o conftest -march=i686 -O3 -pipe conftest.c -lreadline -ltermcap -ldl -lpthread -lutil 1>&5 15:53 <@Azarah> collect2: ld returned 1 exit status 15:53 <@Azarah> configure: failed program was: 15:53 <@Azarah> /usr/i686-pc-linux-gnu/bin/ld: cannot find -ltermcap Gentoo Linux doesn't include libtermcap, so special care should be taken to ensure that our python ebuilds never are put in a situation where they will try to link to libtermcap. On initial inspection, it appears that configure, configure.in, and setup.py are guilty of referring to libtermcap: configure:LIBS="-lreadline -ltermcap $LIBS" configure:LIBS="-lreadline -ltermcap $LIBS" configure.in: AC_DEFINE(HAVE_RL_PRE_INPUT_HOOK), , -ltermcap) configure.in: AC_DEFINE(HAVE_RL_COMPLETION_MATCHES), , -ltermcap) setup.py: ['/usr/lib/termcap'], setup.py: 'termcap'): setup.py: readline_libs.append('termcap') setup.py: library_dirs=['/usr/lib/termcap'], setup.py: curses_libs = ['curses', 'termcap']
AFAICT, the Python configure stuff does the "Right Thing" and there must be something else going on here. I merged readline 4.2a-something (whatever the latest in the archive is) and go no problems in either configure or in building. Note that the failure to find -ltermcap is the "right" thing there. You can ignore the warnings below: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c -o build/temp.linux-i686-2.2/readline.o /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c: In function `set_completer_delims': /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c:278: warning: passing arg 1 of `free' discards qualifiers from pointer target type /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c: In function `flex_complete': /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c:498: warning: implicit declaration of function `completion_matches' /home/jnelson/gentoo-x86/dev-lang/python/Python-2.2.1/Modules/readline.c:498: warning: return makes pointer from integer without a cast gcc -shared build/temp.linux-i686-2.2/readline.o -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncurses -o build/lib.linux-i686-2.2/readline.so The -L/usr/lib/termcap thing is harmless (same as the /usr/local/lib), and note that it *does* use -lncurses as appropriate. Can Azarah give me more info?
I must note that that failure was from the readline tests in the config.log. THus it was not python that failed to compile, but it does mean that readline support for python do not get enabled. Then, why is it the correct behaviour ? If it requires termcap, I should think that you either need libtermcap, or change it to use ncurses.
Are you *sure* readline support isn't compiled in? It works properly for me, despite the "no" (misleading) messages from configure. Note that readline support is built as a module, so python itself shouldn't be linked to readline, but 'import readline' should work.
Lets put it this way. I know next to nothing about how python support readline or ncurses, and if it uses it anyhow. Daniel and I was just trying to resolve a gcc-3.1 wierdness, and I noted that python does not detect readline or ncurses. So if you are 100% sure that this do not cause problems, fine by me.
I am not 100% sure. Due to the way Python builds, if a user installs any one of a number of packages in /usr/local and rebuilds they will get a python that is built differently than those built on "pure" Gentoo machines. That being said, yes. I am sure that in this instance there is not a problem. ;-)
