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: DJ Delorie <dj 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 18:57:11 +0200
- Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
- References: <201105051529.p45FTenR013590@greed.delorie.com> <201105051644.p45Gi9r2002979@d06av02.portsmouth.uk.ibm.com>
On May 5 18:44, Ulrich Weigand wrote:
> DJ Delorie wrote:
> > > I don't know how to avoid this problem in configure, other than by adding
> > > AC_LIBOBJ([psignal]).
> >
> > Right, the correct solution is - libiberty shouldn't provide psignal
> > if newlib does. Making it match newlib is the wrong solution.
>
> I guess I agree, but the problem is exactly how to implement "if newlib
> does" ... Usually, this would be a link test, which libiberty configure
> deliberately avoids for cross-builds, so it hardcodes "what newlib does".
> Do you suggest we should do the link test after all, or make the hard-
> coded newlib capability list somehow dynamic (depending on what)?
>
> Maybe I'm missing something, but I don't understand the AC_LIBOBJ 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])
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat