Version 1.126 of libstdc++-v3/configure.in broke pre-installed newlib builds

[Benjamin Kosnik]

>broke builds where newlib is *pre-installed* (i.e. $with_newlib
>!= yes actually), for example as in my cris-axis-elf test-setup:
>
>...
>configure: error: No support for this host/target combination.
>make[1]: *** [configure-target-libstdc++-v3] Error 1

Well, at least this is doing what I intended....

>Suggestion for a fix?  What was wrong with assuming newlib for
>the default case of a cross-build (as in not matched by the
>other cases in that switch-statement)?  The PR doesn't seem to
>be opposed to that. 

What about this part:

Additionally, when --with-cross-host is defined, libstdc++-v3 assumes
that unless you declare the target as *-*-linux* you are using newlib
and overrides...

> At least newlib could be assumed for an
>otherwise unmatched target (sorry, that should be "host" ;-)

Don't get me started on how messed up it is to configure with --target
and in the configure/build mechanism have this match for host. This
patch was me giving up on sane semantics, and I'm still a little sore
from having to toe the line....

>matching *-*-elf*.  Or if these simple solutions aren't to
>taste, I could cook up an autoconf test for an installed newlib.

Can't you just configure --with-newlib?

What does libiberty do? I'm not quite sure what to do, and kind of think
that the current configure is mostly correct (but there should be a way
for you to get a cross compiler with an installed newlib working. (Maybe
--with-sysroot=foo would work.) 

It would be nice if libiberty and libstdc++ did the same thing, wouldn't
it?

-benjamin