Re: [patch] Allow to link with ncursesw

[John Baldwin <jhb at freebsd dot org>]

On Friday, September 22, 2017 11:21:58 AM Pedro Alves wrote:
> 
> 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.

This seems to work fine in my testing both in the port (which with this
change now only links against libncursesw instead of both) and in my own
builds (which do not use --with-system-readline).

-- 
John Baldwin