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.
> > * libc/sys/linux/Makefile.am (GENERAL_SOURCES): Move psignal.c from
> > here...
> > * libc/signal/Makefile.am (LIB_SOURCES): ... to here.
> > (CHEWOUT_FILES): Add psignal.def.
> > * libc/sys/linux/Makefile.in: Regenerate.
> > * libc/signal/Makefile.in: Ditto.
> > * libc/signal/signal.tex: Add references to psignal.
>
> The patch looks good to me. Please apply.
This breaks building a cross-toolchain to SPU (and probably other newlib
based platforms) with newlib head and GCC head:
/home/kwerner/dailybuild/spu-tc-2011-05-05/gcc-head/src/libiberty/strsignal.c:554:1:
error: conflicting types for 'psignal'
/home/kwerner/dailybuild/spu-tc-2011-05-05/spu-toolchain/spu/include/signal.h:27:6:
note: previous declaration of 'psignal' was here
There are a couple of factors contributing to the problem:
- For one, the libiberty prototype of psignal is probably wrong:
#ifndef HAVE_PSIGNAL
void
psignal (int signo, char *message)
{
newlib has "const char *message" instead (just like glibc).
- On the other hand, as newlib now provides psignal itself, this copy in
libiberty should not actually get built at all ...
- ... however, it does, because of a configure problem. The libliberty
configure.ac tries to avoid link tests when cross-compiling. Therefore,
it simply hard-codes the set of functions it assumes newlib provides:
# We are being configured as a target library. AC_REPLACE_FUNCS
# may not work correctly, because the compiler may not be able to
# link executables. Note that we may still be being configured
# native.
# If we are being configured for newlib, we know which functions
# newlib provide and which ones we will be expected to provide.
if test "x${with_newlib}" = "xyes"; then
AC_LIBOBJ([asprintf])
AC_LIBOBJ([basename])
AC_LIBOBJ([insque])
AC_LIBOBJ([random])
AC_LIBOBJ([strdup])
AC_LIBOBJ([vasprintf])
for f in $funcs; do
case "$f" in
asprintf | basename | insque | random | strdup | vasprintf)
;;
*)
n=HAVE_`echo $f | tr 'abcdefghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
AC_DEFINE_UNQUOTED($n)
;;
esac
done
# newlib doesnt provide any of the variables in $vars, so we
# dont have to check them here.
# Of the functions in $checkfuncs, newlib only has strerror.
AC_DEFINE(HAVE_STRERROR)
setobjs=yes
fi
This list does not include psignal, which indeed newlib did not provide
-- until yesterday, when that patch was committed ...
I'm not quite sure how to fix this ... any suggestions? Did this problem
occur in the past when newlib was extended to provide some new function?
I guess the immediate build problem will disappear once the libiberty
prototype is fixed to include const, but then we'll just have two copies
of psignal (one in newlib, one in libiberty), which may not be ideal
either.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
