This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients akuchling, asmodai, mark.dickinson, r.david.murray, skrah
Date 2010-04-18.15:18:59
SpamBayes Score 4.798643e-09
Marked as misclassified No
Message-id <1271603943.06.0.745457977867.issue7384@psf.upfronthosting.co.za>
In-reply-to
Content
To clarify a couple of things:

On some systems (Redhat?) readline is not linked against ncurses in order to give the user the possibility to choose. This is why setup.py
has to select an ncurses version.

However, things can go wrong if readline is already linked against
a specific ncurses version. On FreeBSD-8.0 this version is ncurses,
but setup.py selects ncursesw:


stefan@freebsd-amd64:~> ldd /lib/libreadline.so.8 
/lib/libreadline.so.8:
        libncurses.so.8 => /lib/libncurses.so.8 (0x800b3e000)
        libc.so.7 => /lib/libc.so.7 (0x800648000)
stefan@freebsd-amd64:~> ls /lib/libncurses*
/lib/libncurses.so.8    /lib/libncursesw.so.8


issue7384.patch suppresses the selection, but is a little primitive.

I've created a new patch, which does the following:

  1) Detect if readline is already linked against ncurses and
     if so, skip any further selection. This must be done.

  2) Use the same version of ncurses for readline.so and _curses.so.


I'm not sure if 2) is necessary. With the previous patch, readline.so
was linked against ncurses and _curses.so against ncursesw. All tests
were passed though.



Any thoughts whether readline.so and _curses.so should link against
the same curses library?
History
Date User Action Args
2010-04-18 15:19:03skrahsetrecipients: + skrah, akuchling, mark.dickinson, asmodai, r.david.murray
2010-04-18 15:19:03skrahsetmessageid: <1271603943.06.0.745457977867.issue7384@psf.upfronthosting.co.za>
2010-04-18 15:19:01skrahlinkissue7384 messages
2010-04-18 15:19:01skrahcreate