Re: [patch] Allow to link with ncursesw

[Pedro Alves <palves at redhat dot com>]

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