gcc --with-newlib vs newlib trunk

[Roland McGrath <mcgrathr at google dot com>]

Do people try configuring gcc using --with-newlib much?
libiberty/configure.ac has this sort of logic:

  # If we are being configured for newlib, we know which functions
  # newlib provide and which ones we will be expected to provide.

This seems severely unwise to me.  But there are probably reasons why
the usual sort of empirical tests for functions provided become more
of a hassle in the --with-newlib cases.

At any rate, this seems to be broken with the newlib trunk.  It now
declares and defines psignal and strsignal, which libiberty/configure.ac
thinks it doesn't.  This causes a compilation error in libiberty/strsignal.c
because libiberty uses the wrong type signature for psignal (missing a const),
thus conflicting with trunk newlib's <signal.h> declaration.

Clearly libiberty's psignal should be declared with a const, which would
fix the proximate problem.  I'll send such a fix to gcc-patches.  But it's
also not so desireable that libiberty is building its own when newlib has
one.  The hard-coded configure logic under --with-newlib is what makes this
difficult, as normal function-by-function checks would discover what the
particular newlib in use does and doesn't have.

Thoughts?


Thanks,
Roland