Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: gdb-patches@sources.redhat.com
Subject: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*
Date: Sat, 24 Apr 2004 11:02:00 -0000	[thread overview]
Message-ID: <20040424110212.19DF64B104@berman.michael-chastain.com> (raw)

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


             reply	other threads:[~2004-04-24 11:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-24 11:02 Michael Elizabeth Chastain [this message]
2004-04-28  0:13 ` Mark Kettenis
2004-04-28  1:51 Michael Elizabeth Chastain
2004-04-28  2:06 ` Joel Brobecker
2004-04-28  3:58 ` Daniel Jacobowitz
2004-04-28 12:29 ` Mark Kettenis
2004-04-28 19:04 Michael Elizabeth Chastain
2004-04-28 20:43 Michael Elizabeth Chastain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040424110212.19DF64B104@berman.michael-chastain.com \
    --to=mec.gnu@mindspring.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox