public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: dj@redhat.com (DJ Delorie)
Cc: vinschen@redhat.com, newlib@sourceware.org,
	gcc-patches@gcc.gnu.org,        yselkowitz@users.sourceforge.net,
	ken.werner@de.ibm.com
Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
Date: Thu, 05 May 2011 17:38:00 -0000	[thread overview]
Message-ID: <201105051732.p45HW6Oe020287@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <201105051700.p45H0ZST016487@greed.delorie.com> from "DJ Delorie" at May 05, 2011 01:00:35 PM

DJ Delorie wrote:
> No, we've always hard-coded what newlib does to avoid the link
> problems.  I think we should continue with that for now.
> 
> I suspect we need to AC_DEFINE(HAVE_PSIGNAL)

Corinna Vinschen had the same suggestion:
> Sorry about that.  I guess that should have been something along the
> lines of
> 
>   AC_DEFINE(HAVE_PSIGNAL,1,[Define if you have psignal])

Just so I understand correctly: adding this AC_DEFINE would *always*
define HAVE_PSIGNAL when configuring libiberty with --with-newlib,
and thus libiberty would never export psignal.

This would of course be fine when building against current newlib
head, because that does provide psignal.  However, when building
against some older newlib version, we still wouldn't get psignal
from libiberty, and therefore not have it available at all, right?

[ Maybe this would be just fine.  GCC for example never calls
  psignal anyway ... ]

If we do add AC_DEFINE(psignal), shouldn't we then also add
AC_DEFINE(strsignal), since this is also provided by newlib
(and having strsignal from libiberty but psignal from newlib,
using two potentially different lists of signal names, would
seem to be just wierd ...)?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2011-05-05 17:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110504111745.GD26180@calimero.vinschen.de>
2011-05-05  9:11 ` Ulrich Weigand
2011-05-05  9:16   ` Corinna Vinschen
2011-05-05  9:24   ` Corinna Vinschen
2011-05-05 16:11     ` DJ Delorie
2011-05-05 16:54       ` Ulrich Weigand
2011-05-05 17:01         ` Corinna Vinschen
2011-05-05 17:02         ` DJ Delorie
2011-05-05 17:38           ` Ulrich Weigand [this message]
2011-05-05 18:27             ` DJ Delorie
2011-05-05 16:57       ` Corinna Vinschen
2011-05-05 17:03         ` DJ Delorie

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=201105051732.p45HW6Oe020287@d06av02.portsmouth.uk.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=dj@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ken.werner@de.ibm.com \
    --cc=newlib@sourceware.org \
    --cc=vinschen@redhat.com \
    --cc=yselkowitz@users.sourceforge.net \
    /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).