From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16750 invoked by alias); 5 May 2005 21:40:29 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 16742 invoked from network); 5 May 2005 21:40:26 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 5 May 2005 21:40:26 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifix.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id D108D169E1; Thu, 5 May 2005 15:54:54 -0700 (PDT) Subject: Re: Another HP-UX IA64 Build patch From: James E Wilson To: DJ Delorie Cc: sje@cup.hp.com, binutils@sources.redhat.com In-Reply-To: <200505052042.j45Kg1Po027434@greed.delorie.com> References: <200505052024.NAA17735@hpsje.cup.hp.com> <200505052042.j45Kg1Po027434@greed.delorie.com> Content-Type: text/plain Message-Id: <1115329225.8413.146.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Thu, 05 May 2005 21:41:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00212.txt.bz2 On Thu, 2005-05-05 at 13:42, DJ Delorie wrote: > Before considering a change to libiberty.h, please check the > following: > * Does configure attempt to discover if a prototype for basename is > already available? > * If so, why is the logic failing in your case? This is somewhat complicated because I don't have access to ia64-hpux, and I'm having to guess on some of this. However, my understanding of the problem is as follows. libiberty.h uses HAVE_DECL_BASENAME. It will provide a prototype only if HAVE_DECL_BASENAME is defined (in which case it comes from the OS), or if HAVE_DECL_BASENAME is defined to zero (in which case it comes from libiberty.h itself). If HAVE_DECL_BASENAME is not defined (i.e. no configure test for it), then libiberty.h provides a non-prototype declaration. gas is compiled with -Wstrict-prototypes -Wmissing-prototypes -Werror, which means a non-prototype declaration will result in a compiler error. This means that if we want to use libiberty.h, we must always have a configure test for basename, regardless of whether we use basename or not. If the configure test is missing, then we will get a compiler error when libiberty.h is included. In opcodes the configure test is there, but opc-ia64.c fails to include config.h before libiberty.h. My patch fixes this. Steve Ellcey has confirmed this in private mail. Unfortunately, there are other files with similar problems in different directories. The list I just got from Steve Ellcey in private mail is gas/as.h and binutils/size.c. In these two cases, we will have to add configure tests for basename, even though we don't call it, in order to avoid the non-prototype definition in libiberty.h. There is a way to hack around this mess. We can modify libiberty.h to define the prototype for hpux when HAVE_DECL_BASENAME is undefined (i.e. the configure check is missing). This hack has already been performed for a number of different operating systems. This hack has not yet been performed for hpux. This is why the problem only shows up on hpux. I am willing to go either way on this if people want to express an opinion here. We can either add extra otherwise unnecessary configure checks for basename, or we can hack libiberty.h for hpux. I suppose there is a third option which is to simplify libiberty.h to always emit the prototype for basename. basename is the only function in libiberty.h for which we can emit a non-prototype when HAVE_DECL_foo is undefined. The others always emit the prototype. I don't know why this is; I haven't tried looking yet. This change is probably no where near as safe as the previous two suggestions. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com