From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2672 invoked by alias); 7 May 2004 13:50:04 -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 2642 invoked from network); 7 May 2004 13:50:01 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sources.redhat.com with SMTP; 7 May 2004 13:50:01 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i47Dnw9x000641; Fri, 7 May 2004 15:49:58 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i47Dnwli019361; Fri, 7 May 2004 15:49:58 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i47Dnq29019350; Fri, 7 May 2004 15:49:52 +0200 (CEST) Date: Fri, 07 May 2004 13:50:00 -0000 Message-Id: <200405071349.i47Dnq29019350@elgar.kettenis.dyndns.org> From: Mark Kettenis To: mec.gnu@mindspring.com CC: gdb-patches@sources.redhat.com In-reply-to: <20040501222714.00E7D4B104@berman.michael-chastain.com> (mec.gnu@mindspring.com) Subject: Re: [patch] configure.in: revert osf5.1 no-noncurses special case References: <20040501222714.00E7D4B104@berman.michael-chastain.com> X-SW-Source: 2004-05/txt/msg00191.txt.bz2 Date: Sat, 1 May 2004 18:27:14 -0400 (EDT) From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Thanks, Michael, we really should avoid special casing in configure.in as much as we can. There's a problem with any platform where a local sysadmin has installed ncurses. The autoconf test looks for the existence of a library, but it does not do anything to add a matching "-I ...." option to $CFLAGS to find the matching header files. There's an additional problem on osf5.1, where the ncurses on some systems requires an additional libtinfo.a library. Indeed. Let's think about a proper way to fix this. The problem here is that the compiler finds certain header files, but the linker doesn't find the associated library, or the other way around. Arguably this is a problem with the configuration of the system. Unfortunately it is a common misconfiguration that we probably can't ignore. GCC searches /usr/local/include by default, but the linker usually doesn't look at /usr/local/lib. The *BSDs modify GCC such that it doesn't do this exactly for that reason. In that case one will have to excplicitly tell configure to look in /usr/local by specifying CPPFLAGS and LDFLAGS. Anyway, we have a couple of options: 1. Prefer a system's native curses library over ncurses. 2. Only use ncurses if we can find both the headers and the associated library. a. Error out if one of the parts if missing. b. Fall back on the system's native curses library if something is missing. 3. Try harder to find all ncurses components by fiddling with CPPFLAGS and LDFLAGS. 4. Unly use ncurses if the user passes --with-ncurses to configure. All solutions have its drawbacks. The system's native curses library may not have all the features that we need/want. So option 1 could lead to build problems, or a non-functional gdbtui where before things would just work if ncurses was available. Option 2a isn't too helpful. If the ncurses is properly installed and fully functional the user should be able to add the right CPPFLAGS and/or LDFLAGS. If not, the only solution would be to remove ncurses. Option 2b is difficult to implement. Option 3 is dangerous. By tweaking CPPFLAGS and LDFLAGS we might invalidate checks for libraries and headers that were done eralier on in the configure script, because we might encounter different versions of the detected components when compiling GDB. Option 4 requires an action by the user. Personally I think we should either go for option 1 or option 4. Mark