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 (Corinna Vinschen), 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:44:09 +0200 (CEST)
- Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
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.
This would add "psignal.o" to the list of object files to be linked into
libiberty. But: 1.) there is no psignal.o / psignal.c in libiberty, but the
symbol psignal is defined within strsignal.c; and 2.) strsignal.o is already
added unconditionally to the list of libiberty objects ... [ But even if we
*did* split psignal into its own object file, that would still not answer
the question of when to link it in and when not. ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com