Re: gcc --with-newlib vs newlib trunk

["Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>]

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:

http://sourceware.org/ml/newlib/2011/msg00165.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00380.html

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


Yaakov
Cygwin/X