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

[Mark Kettenis <kettenis@chello.nl>]

   Date: Sat,  1 May 2004 18:27:14 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

Thanks, Michael, we really should avoid special casing in configure.in
as much as we can.

   There's a problem with any platform where a local sysadmin has installed
   ncurses.  The autoconf test looks for the existence of a library, but it
   does not do anything to add a matching "-I ...." option to $CFLAGS to
   find the matching header files.  There's an additional problem on
   osf5.1, where the ncurses on some systems requires an additional
   libtinfo.a library.

Indeed.  Let's think about a proper way to fix this.  The problem here
is that the compiler finds certain header files, but the linker
doesn't find the associated library, or the other way around.
Arguably this is a problem with the configuration of the system.
Unfortunately it is a common misconfiguration that we probably can't
ignore.  GCC searches /usr/local/include by default, but the linker
usually doesn't look at /usr/local/lib.  The *BSDs modify GCC such
that it doesn't do this exactly for that reason.  In that case one
will have to excplicitly tell configure to look in /usr/local by
specifying CPPFLAGS and LDFLAGS.  Anyway, we have a couple of options:

1. Prefer a system's native curses library over ncurses.

2. Only use ncurses if we can find both the headers and the associated
   library.

   a. Error out if one of the parts if missing.

   b. Fall back on the system's native curses library if something is
   missing.

3. Try harder to find all ncurses components by fiddling with CPPFLAGS
   and LDFLAGS.

4. Unly use ncurses if the user passes --with-ncurses to configure.

All solutions have its drawbacks.  The system's native curses library
may not have all the features that we need/want.  So option 1 could
lead to build problems, or a non-functional gdbtui where before things
would just work if ncurses was available.  Option 2a isn't too
helpful.  If the ncurses is properly installed and fully functional
the user should be able to add the right CPPFLAGS and/or LDFLAGS.  If
not, the only solution would be to remove ncurses.  Option 2b is
difficult to implement.  Option 3 is dangerous.  By tweaking CPPFLAGS
and LDFLAGS we might invalidate checks for libraries and headers that
were done eralier on in the configure script, because we might
encounter different versions of the detected components when compiling
GDB.  Option 4 requires an action by the user.

Personally I think we should either go for option 1 or option 4.

Mark