Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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