This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] configure.in: revert osf5.1 no-noncurses special case
Date: Fri, 7 May 2004 11:33:38 -0400
From: Daniel Jacobowitz <drow@false.org>
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