This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dj at redhat dot com (DJ Delorie)
- Cc: vinschen at redhat dot com, newlib at sourceware dot org, gcc-patches at gcc dot gnu dot org, yselkowitz at users dot sourceforge dot net, ken dot werner at de dot ibm dot com
- Date: Thu, 5 May 2011 19:32:06 +0200 (CEST)
- Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
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