Corinna Vinschen wrote:
On May 4 05:52, Yaakov (Cygwin/X) wrote:
2011-05-04 Yaakov Selkowitz yselkowitz@...
* libc/include/signal.h (psignal): Declare.
* libc/sys/linux/psignal.c: Move from here...
* libc/signal/psignal.c: ... to here. Document.
*
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.
On May 5 11:29, 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.
You don't mean the
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.
You don't mean the prototype, do you? IMHO the char * should still be
changed to const char * to adhere to POSIX.
So far, it's served as a good tool for detecting when libiberty's
configure isn't doing its job :-)
At this point, we should avoid fixing it until the newlib/configure
issue is
DJ Delorie wrote:
No, we've always hard-coded what newlib does to avoid the link
problems. I think we should continue with that for now.
I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
Corinna Vinschen had the same suggestion:
Sorry about that. I guess that should have been something along
