From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: kettenis@chello.nl, mec.gnu@mindspring.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.*
Date: Wed, 28 Apr 2004 01:51:00 -0000 [thread overview]
Message-ID: <20040428015027.7D97E4B104@berman.michael-chastain.com> (raw)
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
next reply other threads:[~2004-04-28 1:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 1:51 Michael Elizabeth Chastain [this message]
2004-04-28 2:06 ` Joel Brobecker
2004-04-28 3:58 ` Daniel Jacobowitz
2004-04-28 12:29 ` Mark Kettenis
-- strict thread matches above, loose matches on Subject: below --
2004-04-28 20:43 Michael Elizabeth Chastain
2004-04-28 19:04 Michael Elizabeth Chastain
2004-04-24 11:02 Michael Elizabeth Chastain
2004-04-28 0:13 ` Mark Kettenis
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=20040428015027.7D97E4B104@berman.michael-chastain.com \
--to=mec.gnu@mindspring.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/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