Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Michael Elizabeth Chastain]

Mark Kettenis writes:
> Sorry, but this isn't right.  Just because ncurses doesn't work on one
> particular system, we shouldn't treat all those systems specially.
> Why is ncurses not working on this particular system?

You're implying that building gdb with ncurses works on *any*
alphaev68-dec-osf5.1 system.  I doubt that it does.

There's no build reports in gdb-testers from anybody with an osf5 system
since 2002.  And based on the build failure in gdb/1626, I don't think
that anybody's actually tried to build on an osf5 system since the
addition of the curses library.  (gdb 6.0 builds fine on this system.
But gdb 6.0 does not use curses; only termcap).

Here's what I get when I build gdb 6.1 with ncurses, but using the right
library order.  The link line is (after touching up the white-space):

  gcc -g -O2 \
    -o gdb gdb.o libgdb.a \
     ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libiberty.a -lncurses -ltermcap -lm ../libiberty/libiberty.a

The unresolved externals are:

  keypad
  cbreak
  _setecho
  nodelay
  _setnonl
  LINES
  COLS
  def_prog_mode
  def_shell_mode
  stdscr
  _acs_map
  curscr
  getcury
  getcurx
  _ring
  savetty
  resetty
  napms
  collect2: ld returned 1 exit status

I'm building gdb with gcc 3.3.3.  This gcc was built with the vendor
assembler and linker, as recommended by the gcc installation
instructions.

On closer inspection, libcurses lives in /usr/shlib, /usr/ccs/lib,
and /usr/lib.  libncurses lives in /usr/local/lib.  I think that's
evidence that libcurses is the official curses library for osf5.1
and libncurses is something local to the machine that I'm using
(spe147.testdrive.hp.com).

I also experimented with a test program that just calls one
library function:

  vendor cc, -lcurses  ... links
  vendor cc, -lncurses ... unresolved external
  gcc, -lcurses  ... links
  gcc, -lncurses ... unresolved external

That just shows that ncurses is broken on the specific host spe147. 
But the location of libcurses and the location of libncurses
leads me to think that libcurses is official on osf5.1 and
libncurses is not.

Michael C

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Joel Brobecker]

> There's no build reports in gdb-testers from anybody with an osf5 system
> since 2002.  And based on the build failure in gdb/1626, I don't think
> that anybody's actually tried to build on an osf5 system since the
> addition of the curses library.  (gdb 6.0 builds fine on this system.
> But gdb 6.0 does not use curses; only termcap).

Actually, we have been building GDB for alphaev67-dec-osf5.1, and it
works just fine. But we don't use ncurses, we build GDB with curses.
I don't know about ncurses, as we don't have it installed on our
Tru64 machines, AFAIK.

(It doesn't change anything to your argument, but I just wanted to
say that we've been building gdb on this platform, and we do it daily
now).

-- 
Joel

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Daniel Jacobowitz]

On Tue, Apr 27, 2004 at 09:50:27PM -0400, Michael Chastain wrote:
> Mark Kettenis writes:
> > Sorry, but this isn't right.  Just because ncurses doesn't work on one
> > particular system, we shouldn't treat all those systems specially.
> > Why is ncurses not working on this particular system?
> 
> You're implying that building gdb with ncurses works on *any*
> alphaev68-dec-osf5.1 system.  I doubt that it does.
> 
> There's no build reports in gdb-testers from anybody with an osf5 system
> since 2002.  And based on the build failure in gdb/1626, I don't think
> that anybody's actually tried to build on an osf5 system since the
> addition of the curses library.  (gdb 6.0 builds fine on this system.
> But gdb 6.0 does not use curses; only termcap).
> 
> Here's what I get when I build gdb 6.1 with ncurses, but using the right
> library order.  The link line is (after touching up the white-space):
> 
>   gcc -g -O2 \
>     -o gdb gdb.o libgdb.a \
>      ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libiberty.a -lncurses -ltermcap -lm ../libiberty/libiberty.a
> 
> The unresolved externals are:
> 
>   keypad
>   cbreak
>   _setecho
>   nodelay
>   _setnonl
>   LINES
>   COLS
>   def_prog_mode
>   def_shell_mode
>   stdscr
>   _acs_map
>   curscr
>   getcury
>   getcurx
>   _ring
>   savetty
>   resetty
>   napms
>   collect2: ld returned 1 exit status

That's a mighty deficient ncurses implementation.  Are they in the
ncurses on your system and not being pulled in?  If they aren't there,
what IS?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Mark Kettenis]

   Date: Tue, 27 Apr 2004 21:50:27 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   Mark Kettenis writes:
   > Sorry, but this isn't right.  Just because ncurses doesn't work on one
   > particular system, we shouldn't treat all those systems specially.
   > Why is ncurses not working on this particular system?

   You're implying that building gdb with ncurses works on *any*
   alphaev68-dec-osf5.1 system.  I doubt that it does.

What I'm saying is that I don't see why gdb wouldn't build on a
*-*-osf5* system with a properly installed ncurses if it builds on the
same system with the vendor's curses library.  What seems to be the
problem here is that on the test-drive system you're using, the
ncurses library isn't properly installed.  This could happen on any
system, even on GNU/Linux systems.  That's no justification to special
case *-*-osf5* in configure.

   On closer inspection, libcurses lives in /usr/shlib, /usr/ccs/lib,
   and /usr/lib.  libncurses lives in /usr/local/lib.  I think that's
   evidence that libcurses is the official curses library for osf5.1
   and libncurses is something local to the machine that I'm using
   (spe147.testdrive.hp.com).

   I also experimented with a test program that just calls one
   library function:

     vendor cc, -lcurses  ... links
     vendor cc, -lncurses ... unresolved external
     gcc, -lcurses  ... links
     gcc, -lncurses ... unresolved external

This makes me wonder why configure doesn't detect ncurses as being broken.

   That just shows that ncurses is broken on the specific host spe147. 
   But the location of libcurses and the location of libncurses
   leads me to think that libcurses is official on osf5.1 and
   libncurses is not.

Yup.  You don't typically find ncurses as the vendor curses library on
commercial UNIXen (as opposed to the Open Source OS'es such as *BSD
and GNU/Linux).  However, GDB prefers ncurses over the vendor curses
library.  I think it is in the GNU spirit to prefer an Open Source
implementation over a proprietary one.  But perhaps more importantly,
ncurses is available on many systems, and provides a uniform
interface.  The vendor's curses implementation may be incomplete or
may have serious bugs.  If we have evidence that this is not the right
strategy, we might change it to prefer the vendor's curses library
over ncurses.  But in order to do that we need more evidence than one
single system that has a broken ncurses.

Could you be so kind to revert the bit of your patch that special
cases *-*-osf5* when looking for a curses library?

Thanks,

Mark

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> That's a mighty deficient ncurses implementation.  Are they in the
> ncurses on your system and not being pulled in?  If they aren't there,
> what IS?

That's a fruitful line of inquiry.

/usr/local/lib/libncurses.a is a version of ncurses 5.2.
But the "tinfo" subdirectory of ncurses has been built as a separate
library, so I have to link gdb with "-lncurses -ltinfo".
This is similar to the situation on hpux where libcur_colr.a is
needed for 'wborder'.

There is another problem.  configure.ac is finding libncurses.a in
/usr/local/lib, but it is not looking for include files in
/usr/local/include.  So gdb is using /usr/include/curses.h at compile
time and /usr/local/lib/libncurses.a at link time.  Fortunately, this
just causes unresolved externals on my particular system.

I worked around *that* problem with "-I /usr/local/include/ncurses".
Now I get a gdbtui that links and runs, but it crashes shortly after
"break main; run; next; next".

Michael C

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Michael Elizabeth Chastain]

Mark Kettenis writes:
> What I'm saying is that I don't see why gdb wouldn't build on a
> *-*-osf5* system with a properly installed ncurses if it builds on the
> same system with the vendor's curses library.

Okay, I've tried that.  I built ncurses 5.4 from source, built gdb with
it, and it linked and ran.  gdbtui opens windows properly.

> What seems to be the problem here is that on the test-drive system
> you're using, the ncurses library isn't properly installed.

That's true, because /usr/local/lib/libncurses.a is missing a lot
of entry points which are described in the locally installed
documentation for ncurses on that system.

> This makes me wonder why configure doesn't detect ncurses as being broken.

configure links a C program with an extern for 'initscr'.
/usr/local/lib/ncurses.a resolves 'initscr' so configure
thinks that the whole library works.

> However, GDB prefers ncurses over the vendor curses library.  I think it
> is in the GNU spirit to prefer an Open Source implementation over a
> proprietary one.

Spirit is fine, but we've got actual results from two systems.
The system that Joel uses has no ncurses, and the system that
I use has a broken ncurses.  So far nobody has pointed to a system
with a working ncurses.

> The vendor's curses implementation may be incomplete or
> may have serious bugs.

That's true.  That's why I actually ran gdbtui after building it
and watched the full-screen version working.

> Could you be so kind to revert the bit of your patch that special
> cases *-*-osf5* when looking for a curses library?

Well, okay.  I'll do that.

Michael C

Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Mark Kettenis]

   Date: Sat, 24 Apr 2004 07:02:12 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   This patch fixes gdb/1626, build failure on native alphaev58-dec-osf5.1 .

   The second problem is that ncurses does not work on the system that
   I'm using (an HP test drive alpha system).  So I just added some
   logic with "case osf5.*)" to probe a shorter list of curses libraries
   on that system.

Sorry, but this isn't right.  Just because ncurses doesn't work on one
particular system, we shouldn't treat all those systems specially.
Why is ncurses not working on this particular system?

Mark

[patch] configure.ac, configure: curses/termcap on *-*-osf5.*

[Michael Elizabeth Chastain]

This patch fixes gdb/1626, build failure on native alphaev58-dec-osf5.1 .

There are two problems.  The first problem is that the autoconf macros
builds the library list from right-to-left, so that configure.in
should probe for the lowest library first: termcap *before* curses.
The second problem is that ncurses does not work on the system that
I'm using (an HP test drive alpha system).  So I just added some
logic with "case osf5.*)" to probe a shorter list of curses libraries
on that system.

Testing: I built gdb on:

  native alphaev68-dec-osf5.1
  native hppa2.0w-hp-hpux11.11
  native i386-unknown-freebsd4.9
  native i686-pc-linux-gnu

I also executed gdb on alphaev68-dec-osf5.1 .  "gdb gdb" with
"break main; run" works.  And "gdbtui gdb" with "break main; run"
works, and the tui displays properly.

According to MAINTAINERS, configure* can be edited by "ALL".
So I'll wait 24 hours and if there is no objection, commit this.

Michael C

===

2004-04-24  Michael Chastain  <mec.gnu@mindspring.com>

	Fix PR gdb/1626.
	* configure.in: Check for curses after termcap.
	On osf5.*, do not check for ncurses.
	* configure: Regenerate.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.150
diff -c -3 -p -r1.150 configure.in
*** configure.in	29 Mar 2004 18:07:14 -0000	1.150
--- configure.in	24 Apr 2004 10:24:43 -0000
*************** if test x"$enable_gdbmi" = xyes; then
*** 135,160 ****
    fi
  fi
  
- # FIXME: kettenis/20030102: We seem to prefer HP curses (Hcurses) over
- # Xcurses on HP-UX; see the `-D__HP_CURSES' in the relevant host
- # Makefile fragments.  That's why we need to have `Hcurses' before
- # `curses'.  I don't see why we should use HP curses if a more
- # standard curses is available, except that according to HP's
- # documentation one needs to compile `-D_XOPEN_SOURCE_EXTENDED' on
- # HP-UX 10.10 and 10.20.
- 
- AC_SEARCH_LIBS(initscr, [ncurses Hcurses curses pdcurses], [],
-     [AC_MSG_WARN([no curses library found])])
- 
- # Check whether the wborder function is provided by the curses
- # library detected above.  In certain implementations such as
- # the HP/UX Hcurses for instance, this function is provided by an
- # additional library.  So if we did not find this function inside
- # the curses library, try some alternate libraries we know might
- # provide it.
- AC_SEARCH_LIBS(wborder, [cur_colr], [],
-     [AC_MSG_WARN([wborder function not found, tui will be disabled])])
- 
  # Enable TUI.
  AC_ARG_ENABLE(tui,
  [  --enable-tui            enable full-screen terminal user interface (TUI)],
--- 135,140 ----
*************** AC_SEARCH_LIBS(tgetent, [termcap tinfo n
*** 330,335 ****
--- 310,345 ----
  if test "$ac_cv_search_tgetent" = no; then
    AC_MSG_ERROR([no termcap library found])
  fi
+ 
+ # FIXME: kettenis/20030102: We seem to prefer HP curses (Hcurses) over
+ # Xcurses on HP-UX; see the `-D__HP_CURSES' in the relevant host
+ # Makefile fragments.  That's why we need to have `Hcurses' before
+ # `curses'.  I don't see why we should use HP curses if a more
+ # standard curses is available, except that according to HP's
+ # documentation one needs to compile `-D_XOPEN_SOURCE_EXTENDED' on
+ # HP-UX 10.10 and 10.20.
+ 
+ case $host_os in
+   osf5.*)
+     # ncurses does not work on native alphaev68-dec-osf5.1
+     # -- chastain 2004-04-24
+     AC_SEARCH_LIBS(initscr, [curses], [],
+       [AC_MSG_WARN([no curses library found])])
+     ;;
+   *)
+     AC_SEARCH_LIBS(initscr, [ncurses Hcurses curses pdcurses], [],
+       [AC_MSG_WARN([no curses library found])])
+     ;;
+ esac
+ 
+ # Check whether the wborder function is provided by the curses
+ # library detected above.  In certain implementations such as
+ # the HP/UX Hcurses for instance, this function is provided by an
+ # additional library.  So if we did not find this function inside
+ # the curses library, try some alternate libraries we know might
+ # provide it.
+ AC_SEARCH_LIBS(wborder, [cur_colr], [],
+     [AC_MSG_WARN([wborder function not found, tui will be disabled])])
  
  # ------------------------- #
  # Checks for header files.  #