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: Corinna Vinschen <vinschen at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: newlib at sourceware dot org, gcc-patches at gcc dot gnu dot org, yselkowitz at users dot sourceforge dot net, dj at redhat dot com, ken dot werner at de dot ibm dot com
- Date: Thu, 5 May 2011 11:23:34 +0200
- Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
- References: <20110504111745.GD26180@calimero.vinschen.de> <201105050909.p4599SUA010092@d06av02.portsmouth.uk.ibm.com>
On May 5 11:09, Ulrich Weigand wrote:
> This list does not include psignal, which indeed newlib did not provide
> -- until yesterday, when that patch was committed ...
>
>
> I'm not quite sure how to fix this ... any suggestions? Did this problem
> occur in the past when newlib was extended to provide some new function?
>
> I guess the immediate build problem will disappear once the libiberty
> prototype is fixed to include const, but then we'll just have two copies
> of psignal (one in newlib, one in libiberty), which may not be ideal
> either.
Developers using libiberty don't have to use newlib so the definition
in libiberty still makes sense, right?
I don't know how to avoid this problem in configure, other than by adding
AC_LIBOBJ([psignal]).
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat