gcc --with-newlib vs newlib trunk

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Thu Nov 3 03:33:00 GMT 2011

On Tue, 2011-10-18 at 09:43 -0700, Roland McGrath wrote:
> 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?

This was discussed earlier when psignal and strsignal were first added
to newlib, thread beginning here:


What conclusion was made, if any, I do not recall.


More information about the Newlib mailing list