public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: DJ Delorie <dj@redhat.com>
Cc: sje@cup.hp.com, binutils@sources.redhat.com
Subject: Re: Another HP-UX IA64 Build patch
Date: Thu, 05 May 2005 21:41:00 -0000	[thread overview]
Message-ID: <1115329225.8413.146.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <200505052042.j45Kg1Po027434@greed.delorie.com>

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


  reply	other threads:[~2005-05-05 21:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-05 17:26 Steve Ellcey
2005-05-05 17:41 ` Daniel Jacobowitz
2005-05-05 17:55   ` Steve Ellcey
2005-05-05 18:12     ` James E Wilson
2005-05-05 18:16       ` Daniel Jacobowitz
2005-05-05 19:17         ` James E Wilson
2005-05-05 19:32       ` DJ Delorie
2005-05-05 19:47         ` James E Wilson
2005-05-05 21:40       ` Andreas Schwab
2005-05-05 21:43         ` DJ Delorie
2005-05-05 18:10 ` James E Wilson
2005-05-05 20:12 ` James E Wilson
2005-05-05 20:42   ` Steve Ellcey
2005-05-05 21:36     ` DJ Delorie
2005-05-05 21:41       ` James E Wilson [this message]
2005-05-05 22:46         ` DJ Delorie
2005-05-06  1:57           ` James E Wilson
2005-05-06  1:58             ` DJ Delorie
2005-05-09 23:28               ` Steve Ellcey
2005-05-09 23:33                 ` DJ Delorie
2005-05-12 16:37                   ` Steve Ellcey
2005-05-05 22:06   ` James E Wilson

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=1115329225.8413.146.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=binutils@sources.redhat.com \
    --cc=dj@redhat.com \
    --cc=sje@cup.hp.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).