From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11294 invoked by alias); 25 Sep 2017 18:34:43 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 11285 invoked by uid 89); 25 Sep 2017 18:34:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*r:sk:c-73-23, H*RU:sk:c-73-23, Hx-spam-relays-external:sk:c-73-23, UD:7 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Sep 2017 18:34:41 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id E472910AF07; Mon, 25 Sep 2017 14:34:38 -0400 (EDT) From: John Baldwin To: Pedro Alves Cc: Matthias Klose , gdb-patches@sourceware.org Subject: Re: [patch] Allow to link with ncursesw Date: Mon, 25 Sep 2017 18:34:00 -0000 Message-ID: <6369122.laJjuqZJ79@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <3e48c0e2-d870-c421-7c5a-49c00ca2bbf1@redhat.com> References: <3057121.ifSOzBUOOt@ralph.baldwin.cx> <3e48c0e2-d870-c421-7c5a-49c00ca2bbf1@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00760.txt.bz2 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