From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24244 invoked by alias); 28 Apr 2004 01:51:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23951 invoked from network); 28 Apr 2004 01:51:37 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sources.redhat.com with SMTP; 28 Apr 2004 01:51:37 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1BIeES-0006Zv-00; Tue, 27 Apr 2004 21:51:30 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 7D97E4B104; Tue, 27 Apr 2004 21:50:27 -0400 (EDT) To: kettenis@chello.nl, mec.gnu@mindspring.com Subject: Re: [patch] configure.ac, configure: curses/termcap on *-*-osf5.* Cc: gdb-patches@sources.redhat.com Message-Id: <20040428015027.7D97E4B104@berman.michael-chastain.com> Date: Wed, 28 Apr 2004 01:51:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-04/txt/msg00625.txt.bz2 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