Re: [patch] Allow to link with ncursesw

Pedro Alves
2017-09-22T10:22:07Z

On 09/21/2017 12:56 AM, John Baldwin wrote:
> On Wednesday, September 20, 2017 10:22:29 PM Pedro Alves wrote:
>> On 09/20/2017 08:51 PM, Matthias Klose wrote:
>>> On 20.09.2017 20:39, Pedro Alves wrote:
>>
>>>> Did you reach out to readline/bash, see if they're willing
>>>> to try ncursesw before ncurses too? Don't we need at least
>>>> a local patch to our local readline copy, to avoid breaking
>>>> those that use it and have it link with ncurses?
>>>
>>> afaik, this is only the case if readline is linked with one of the curses
>>> libraries. However these days everybody seems to have readline linked to just
>>> tinfo, so this shouldn't be an issue?
>>
>> Everybody on GNU/Linux, it seems. However, the Python bug
>> report talked about FreeBSD's readline linked with ncurses
>> Do you know whether they've switched to tinfo as well
>> meanwhile? [Adding John as FreeBSD maintainer.]
>
> FreeBSD still links libreadline against curses:
>
> % ldd /usr/local/lib/libreadline.so.7
> /usr/local/lib/libreadline.so.7:
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x801251000)
> libc.so.7 => /lib/libc.so.7 (0x800825000)
>
> However, it seems to be linked against libncursesw. gdb on this same
> system (11.1) is linked against both ncurses libraries:
>
> % ldd /usr/local/bin/gdb80
> /usr/local/bin/gdb80:
> libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0x801dda000)
> libncurses.so.8 => /lib/libncurses.so.8 (0x80202b000)
> libkvm.so.7 => /lib/libkvm.so.7 (0x802281000)
> libutil.so.9 => /lib/libutil.so.9 (0x80248f000)
> libm.so.5 => /lib/libm.so.5 (0x8026a3000)
> libthr.so.3 => /lib/libthr.so.3 (0x8028cd000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x802af5000)
> libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x802d00000)
> libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8030e3000)
> liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80330e000)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x803537000)
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x803801000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x803a20000)
> libc.so.7 => /lib/libc.so.7 (0x803c2f000)
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x803fec000)
> libelf.so.2 => /lib/libelf.so.2 (0x80424b000)
>
> Given that readline on FreeBSD now uses ncursesw and that the original
> python report was from several years ago when that probably wasn't true,
> I'm inclined to think that using ncursesw might be fine. I'll try a test
> build of this patch tomorrow.
>

Thanks! If you could also confirm with the in-tree readline
as well (i.e., without --with-system-readline), that'd be great. The
original Python reports I linked at were about readline compiled against
ncurses and then something else linked against ncursesw, IIUC. I don't
know whether that might make a difference, but I guess it could, if
readline is compiled against some curses structure that ends up
mismatching with the called curses functions due to odd interposition
effects.

If that causes a problem, then we may need to patch our local
readline copy matching gdb.

Otherwise, if all is fine, then I think we've given this
due diligence and Matthias' patch is fine with me.

Thanks,
Pedro Alves