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.

classification
Title: curses: Link against libncursesw instead of libncurses
Type: Stage:
Components: Library (Lib), Unicode Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, akuchling, asmodai, eric.araujo, mark.dickinson, pitrou, r.david.murray, rpetrov, skrah, vstinner
Priority: normal Keywords:

Created on 2010-07-28 23:49 by vstinner, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (8)
msg111875 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-07-28 23:49
Because of #7384, Python3 now links _curses.so to ncurses library (bytes version) instead of ncursesw library (unicode version) if readline is linked to ncurses. I'm using Linux (Debian Sid).

On Linux, Python3 should maybe only link to the unicode version, because the bytes version has many issues with unicode and lacks many functions.

See also:
 - #1428494: "Prefer linking against ncursesw over ncurses library" (so I consider this issue as a regression).
 - #4787

(reuse the nosy list from #7384)
msg116056 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-09-10 22:39
Does anyone agree with me?
msg116058 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-09-10 23:21
Just a short explanation: 

In #7384 I used the strict version of the patch for 2.7/3.2 because Thomas Dickey recommended not to load readline+ncurses and ncursesw
at the same time.

Actually the distros should either link readline against libtinfo
(Fedora) or only use ncursesw (DragonFly).


If someone feels confident that on Linux the linker can safely handle
conflicting global symbols in this situation, the patch for 2.6/3.1
could be used.
msg116070 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-09-11 00:42
$ ldd $(/usr/bin/python3.1 -c 'import readline; print(readline.__file__)')|grep curses
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7537000)
$ ldd /lib/libreadline.so.6|grep curses
        libncurses.so.5 => /lib/libncurses.so.5 (0xb76a6000)

> Actually the distros should either link readline 
> against libtinfo (Fedora) or only use ncursesw (DragonFly).

Ok, I should maybe open a *Debian* bug to ask to link readline to ncursesw (and another to ensure that Python3 is also liked to ncursesw).
msg119506 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-10-24 11:10
There are two issues here:

(1) If libreadline is already linked against ncurses, there is no way that
    the readline module should be linked against ncursesw. This was the
    direct cause of the FreeBSD segfault, so this configuration is also
    prohibited in 2.6/3.1.

(2) Interaction between the readline and curses modules: 2.6/3.1 still
    allow readline+ncurses with curses+ncursesw. To be on the safe side,
    2.7/3.2 enforce all ncurses or all ncursesw.


(1) implies that if your readline module is linked against ncurses in 3.1,
you should find that libreadline is also linked against ncurses.
msg119508 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-10-24 11:16
Hmm, I understood that your ldd lines implied that things don't work as
intended in 3.1, hence the explanation. Perhaps this wasn't the case. :)
msg140425 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-07-15 15:44
For the record, I filed the following bug against Mageia's libreadline:
https://bugs.mageia.org/show_bug.cgi?id=2156
msg156374 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-03-20 00:39
> I should maybe open a *Debian* bug

Done:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602720

I don't think that we should drop support of libncurses because it is still the only option on some OSes. I'm closing the issue because it is now fixed in Debian which was my initial concern.
History
Date User Action Args
2022-04-11 14:57:04adminsetgithub: 53654
2012-03-20 00:39:36vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg156374
2012-03-08 15:49:52eric.araujosetnosy: + eric.araujo
2011-07-15 15:44:30pitrousetnosy: + pitrou
messages: + msg140425
2010-10-24 11:16:47skrahsetmessages: + msg119508
2010-10-24 11:10:31skrahsetmessages: + msg119506
2010-09-11 00:42:47vstinnersetmessages: + msg116070
2010-09-10 23:21:02skrahsetmessages: + msg116058
2010-09-10 22:39:54vstinnersetmessages: + msg116056
2010-07-28 23:49:50vstinnercreate