Re: [patch] configure.in: revert osf5.1 no-noncurses special case

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

> 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?

On systems where ncurses is the default library, it looks like curses.
curses.h -> ncurses.h, libcurses.a -> libncurses.a.

Or you could have this search order:

  --with-ncurses if explicit specified
  system ncurses
  system curses

> 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.

I think it's normal.

I'm using gcc to build gdb, but I can't use the binutils linker.  The
gcc doco says: use the system linker.  The system linker looks in
/usr/local/lib, but the gcc preprocessor doesn't look in
/usr/local/include.

So if anything's broken on this system, it's actually gcc.  I could fall
back and use the vendor compiler to build gdb.

> 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.

Right now I have *no way to fix it*.  I built ncurses 5.2, ncurses 5.3,
and ncurses 5.4 on this system, and I built gdbtui with each of them and
ran each of them.  All of them work.  But I had to hack the Makefile to
do it, because there is no configuration option to tell gdb to use
$MIGCHAIN_DIR_INSTALL/host/ncurses-5.4.  (And I can't install any
software as root on this system).

Suppose I want to test a new version of ncurses?

Suppose I have an oddball platform and I need to patch ncurses in
order to use it?

> 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.

Well, right now we're using library search tests, which do not look
for header files at all.  That's where the false positives are coming
from at configure time.

My experience with other packages is that they use --with options
to find other programs and libraries.  Such as:

  gcc       --with-gnu-as --with-gnu-ld
  dejagnu   --with-tclinclude
  expect    --with-tcl

Michael C