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.weig...@de.ibm.com
