From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17932 invoked by alias); 7 May 2004 16:49:17 -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 17882 invoked from network); 7 May 2004 16:49:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 May 2004 16:49:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.32 #1 (Debian)) id 1BM8XD-0006R2-0a; Fri, 07 May 2004 12:49:15 -0400 Date: Fri, 07 May 2004 16:49:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: mec.gnu@mindspring.com, gdb-patches@sources.redhat.com Subject: Re: [patch] configure.in: revert osf5.1 no-noncurses special case Message-ID: <20040507164914.GB24613@nevyn.them.org> Mail-Followup-To: Mark Kettenis , mec.gnu@mindspring.com, gdb-patches@sources.redhat.com References: <20040507151048.CA6424B104@berman.michael-chastain.com> <20040507153338.GA22511@nevyn.them.org> <200405071619.i47GJ5S4065835@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405071619.i47GJ5S4065835@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-05/txt/msg00209.txt.bz2 On Fri, May 07, 2004 at 06:19:05PM +0200, Mark Kettenis wrote: > 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. I would have expected there to be such systems. Maybe there aren't. In any case, ncurses is the GNU curses library, so I still think it's appropriate to prefer it. > 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. At which point it's the user's responsibility to set LDFLAGS, IMO. Note that if you do that with ncurses, you'll probably get a shared library in a non-system directory, so this is just the beginning of your problems. -- Daniel Jacobowitz