From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2036 invoked by alias); 7 May 2004 16:19:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2013 invoked from network); 7 May 2004 16:19:45 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sources.redhat.com with SMTP; 7 May 2004 16:19:45 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i47GJ99x000884; Fri, 7 May 2004 18:19:09 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i47GJ9li065845; Fri, 7 May 2004 18:19:09 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i47GJ5S4065835; Fri, 7 May 2004 18:19:05 +0200 (CEST) Date: Fri, 07 May 2004 16:19:00 -0000 Message-Id: <200405071619.i47GJ5S4065835@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@false.org CC: mec.gnu@mindspring.com, gdb-patches@sources.redhat.com In-reply-to: <20040507153338.GA22511@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 7 May 2004 11:33:38 -0400) Subject: Re: [patch] configure.in: revert osf5.1 no-noncurses special case References: <20040507151048.CA6424B104@berman.michael-chastain.com> <20040507153338.GA22511@nevyn.them.org> X-SW-Source: 2004-05/txt/msg00206.txt.bz2 Date: Fri, 7 May 2004 11:33:38 -0400 From: Daniel Jacobowitz On Fri, May 07, 2004 at 11:10:48AM -0400, Michael Chastain wrote: > Hi Mark, > > Yeah, I was unhappy about reverting the patch, but in the long run, > the problem is not really specific to osf5.1, so it's better to > solve the real problem. > > > 4. Unly use ncurses if the user passes --with-ncurses to configure. > > I prefer this solution the best. We've had similar requests for > readline from people who want to use the system readline library > or their own readline library rather than our bundled readline. > And this way a clueful user has the maximum usability, while a > no-customization user has a good chance of getting a working gdb > and even a gdbtui. I think this is a bad idea. Remember, there's this huge base of installed systems where ncurses is the default library and/or installed in a system directory. Why penalize them? Most of the open source systems use ncurses as the native curses libraries. On such systems, ncurses is either installed as libncurses (OpenBSD) or there is a link from libcurses to libcurses (FreeBSD, Debian GNU/Linux). The headers are treated in a similar way. I'm certainly not proposing to detect whether libcurses is actually libncurses, and refuse to use libcurses in that case. I'm just proposing to search for libcurses and ncurses.h only if --with-ncurses is specified. I really doubt that there are really any systems out there where ncurses is installed in a system directory alongside with the native curses library where the two are not one and the same. If there are such systems out there, we'd only penalize them if the native curses library is somehow broken. > The advantage of the current scheme (option #0) is that it might work > on some systems. I'm unhappy with #0 because I know that it doesn't > work on my hp test drive system. As I understand it, you are unhappy > with #1 for the converse reason: the configury can automatically make > a bad choice on some systems. But the reason it doesn't work on your HP test drive system is a broken or extremely unusual installation of ncurses, so I don't want to make policy decisions for GDB based on it. Personally, I don't see the point in worrying about this. If you've got a broken ncurses installation - one where the linker finds -lncurses but gcc doesn't, or vice versa, is broken in my book - it's your problem. It's broken in my book too, but it's very likely that you'll end up in that situation if you install GCC and ncurses using ./configure && make && make install on almost any UNIX system. I believe that checking for whichever header we are going to use is the appropriate decision. Then, if that fails, either error out or disable gdbtui. This is what the thousands of other software packages using non-system libraries do. We certainly should disable the TUI if something is amiss. To my amazement we currently don't do that. Mark