From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Jerome Guitton <guitton@adacore.com>
Subject: [RFA] Add --with-curses configure option
Date: Fri, 13 Mar 2009 02:21:00 -0000 [thread overview]
Message-ID: <20090313020640.GE11284@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Hello,
Last October, I checked in a patch that made sure that GDB would
use the "minimal" termcap/curses library that it could find.
This was necessary in order to align GDB with readline, thus
make sure that readline and GDB use the same terminal library.
This fixed a nasty issue on Tru64 were readline wanted to use
libtermcap whereas gdb wanted to use ncurses. See:
http://www.sourceware.org/ml/gdb-patches/2008-10/msg00071.html.
One of the consequences, is that we started building GDB with
libtermcap.so on some of our GNU/Linux machines, if libtermcap
was found. As it turns out, it appears that most distributions
are no longer providing the symbolic link between libtermcap and
libcurses. This is a problem for binary distribution because
customer tried to install our binary on their machine, and found
that there was a missing dependency.
The attached patch introduced a new --with-curses configure switch,
which follows what readline already does. That way, if one configures
with --with-curses, both readline and gdb will remain consistent
and use a curses library.
2009-02-13 Jerome Guitton <guitton@adacore.com>
* configure.ac: Add --with-curses.
* configure: Regenerated.
Tested on all our supported platforms (AdaCore builds GDB with
--with-curses on all GNU/Linux hosts we support, and without it
on all the other ones).
Any objection to checking this change in? Daniel, might be useful
to CS as well, if you guys ship debuggers hosted on GNU/Linux like
we do.
--
Joel
[-- Attachment #2: 10-with-curses.diff --]
[-- Type: text/x-diff, Size: 2355 bytes --]
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 3f81ff2..9b15a42 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -331,6 +331,13 @@ if test x"$enable_libunwind" = xyes; then
CONFIG_SRCS="$CONFIG_SRCS libunwind-frame.c"
fi
+opt_curses=no
+AC_ARG_WITH(curses, AC_HELP_STRING([--with-curses], [use the curses library instead of the termcap library]), opt_curses=$withval)
+
+if test "$opt_curses" = "yes"; then
+ prefer_curses=yes
+fi
+
# Profiling support.
AC_ARG_ENABLE(profiling,
[ --enable-profiling enable profiling of GDB],
@@ -457,22 +464,32 @@ case $host_os in
;;
esac
+# For the TUI, we need enhanced curses functionality.
+if test x"$enable_tui" = xyes; then
+ prefer_curses=yes
+fi
+
+curses_found=no
+if test x"$prefer_curses" = xyes; then
+ # FIXME: kettenis/20040905: We prefer ncurses over the vendor-supplied
+ # curses library because the latter might not provide all the
+ # functionality we need. However, this leads to problems on systems
+ # where the linker searches /usr/local/lib, but the compiler doesn't
+ # search /usr/local/include, if ncurses is installed in /usr/local. A
+ # default installation of ncurses on alpha*-dec-osf* will lead to such
+ # a situation.
+ AC_SEARCH_LIBS(waddstr, [ncurses cursesX curses])
+
+ if test "$ac_cv_search_waddstr" != no; then
+ curses_found=yes
+ fi
+fi
+
# Check whether we should enable the TUI, but only do so if we really
# can.
if test x"$enable_tui" != xno; then
if test -d $srcdir/tui; then
- # For the TUI, we need enhanced curses functionality.
- #
- # FIXME: kettenis/20040905: We prefer ncurses over the vendor-supplied
- # curses library because the latter might not provide all the
- # functionality we need. However, this leads to problems on systems
- # where the linker searches /usr/local/lib, but the compiler doesn't
- # search /usr/local/include, if ncurses is installed in /usr/local. A
- # default installation of ncurses on alpha*-dec-osf* will lead to such
- # a situation.
- AC_SEARCH_LIBS(waddstr, [ncurses cursesX curses])
-
- if test "$ac_cv_search_waddstr" != no; then
+ if test "$curses_found" != no; then
CONFIG_OBS="$CONFIG_OBS \$(SUBDIR_TUI_OBS)"
CONFIG_DEPS="$CONFIG_DEPS \$(SUBDIR_TUI_DEPS)"
CONFIG_SRCS="$CONFIG_SRCS \$(SUBDIR_TUI_SRCS)"
next reply other threads:[~2009-03-13 2:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-13 2:21 Joel Brobecker [this message]
2009-03-24 1:33 ` Joel Brobecker
2009-03-24 15:40 ` Jan Kratochvil
2009-03-24 16:13 ` Joel Brobecker
2009-03-24 16:41 ` Jan Kratochvil
2009-03-24 16:57 ` Joel Brobecker
2009-03-24 17:04 ` Jan Kratochvil
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=20090313020640.GE11284@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=guitton@adacore.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