From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8965 invoked by alias); 7 May 2004 15:52:46 -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 8951 invoked from network); 7 May 2004 15:52:45 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sources.redhat.com with SMTP; 7 May 2004 15:52:45 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1BM7eV-0003cw-00; Fri, 07 May 2004 11:52:43 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 850714B104; Fri, 7 May 2004 11:52:27 -0400 (EDT) To: drow@false.org, mec.gnu@mindspring.com Subject: Re: [patch] configure.in: revert osf5.1 no-noncurses special case Cc: gdb-patches@sources.redhat.com, kettenis@chello.nl Message-Id: <20040507155227.850714B104@berman.michael-chastain.com> Date: Fri, 07 May 2004 15:52:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-05/txt/msg00205.txt.bz2 > I think this is a bad idea. Remember, there's this huge base of > installed systems where ncurses is the default library and/or installed > in a system directory. Why penalize them? On systems where ncurses is the default library, it looks like curses. curses.h -> ncurses.h, libcurses.a -> libncurses.a. Or you could have this search order: --with-ncurses if explicit specified system ncurses system curses > But the reason it doesn't work on your HP test drive system is a broken > or extremely unusual installation of ncurses, so I don't want to make > policy decisions for GDB based on it. I think it's normal. I'm using gcc to build gdb, but I can't use the binutils linker. The gcc doco says: use the system linker. The system linker looks in /usr/local/lib, but the gcc preprocessor doesn't look in /usr/local/include. So if anything's broken on this system, it's actually gcc. I could fall back and use the vendor compiler to build gdb. > Personally, I don't see the point in worrying about this. If you've got > a broken ncurses installation - one where the linker finds -lncurses but > gcc doesn't, or vice versa, is broken in my book - it's your problem. Right now I have *no way to fix it*. I built ncurses 5.2, ncurses 5.3, and ncurses 5.4 on this system, and I built gdbtui with each of them and ran each of them. All of them work. But I had to hack the Makefile to do it, because there is no configuration option to tell gdb to use $MIGCHAIN_DIR_INSTALL/host/ncurses-5.4. (And I can't install any software as root on this system). Suppose I want to test a new version of ncurses? Suppose I have an oddball platform and I need to patch ncurses in order to use it? > I believe that checking for whichever header we are going to use is the > appropriate decision. Then, if that fails, either error out or disable > gdbtui. This is what the thousands of other software packages using > non-system libraries do. Well, right now we're using library search tests, which do not look for header files at all. That's where the false positives are coming from at configure time. My experience with other packages is that they use --with options to find other programs and libraries. Such as: gcc --with-gnu-as --with-gnu-ld dejagnu --with-tclinclude expect --with-tcl Michael C