http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49247
Summary: libiberty configure assumes newlib does not supply
psignal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
A build of GCC mainline for arm-none-eabi using mainline newlib fails
with:
/scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/libiberty/strsignal.c:554:1:
error: conflicting types for 'psignal'
/scratch/janisjo/arm-eabi-fsf/install/arm-none-eabi/include/signal.h:27:6:
note: previous declaration of 'psignal' was here
where the installed version comes from newlib. The libiberty version has
an argument with "char *" and the newlib version uses "const char *" for
that argument.
The newlib version of psignal was added on 2011-05-04.
The libiberty version of psignal is not compiled if HAVE_PSIGNAL is
defined, but when building against newlib it is never defined.
libiberty/configure.ac says:
# If we are being configured for newlib, we know which functions
# newlib provide and which ones we will be expected to provide.
and
# Of the functions in $checkfuncs, newlib only has strerror.
This is no longer true, as the latest newlib now has psignal as well.
It could also be the case that later versions of newlib will have other
funtions in $checkfuncs.
