libstdc++/6827: Unreasonable dependencies on ctype.h

[Tony Bryant]

> > How valid is the assumption that we'll be using always be using newlib on
> > cross compilers?
>
> It's not so much an assumption, rather it's nobody has contributed support
> for any other embedded C library to libstdc++-v3.

Actually they already have. "config/os/generic" works for any C library with 
just the ISO standard ctype.h calls.

Funnily enough "config/os/generic"[1] is already the catchall for non-cross 
builds, but "config/os/newlib"[2] is for cross builds. A touch bizzare, not 
to even mention configure telling me lies about what config is being used.

[1] see configure.target
[2] see configure.in[3]
[3] is it just me, or is this hack for cross compiles just a touch crufty???

> "Embedded" isn't actually a requirement here, of course.  It's just that
> newlib also makes a darn good portable C library, sort of as a byproduct
> of being targeted to embedded platforms.  /That's/ why we use it.

Its admittedly very good,  but for various reasons it doesn't suit everybody. 
This ctype.h dependency is the ONLY specific attachment that libstdc++ has to 
it. Otherwise it does work with ANY standard C library.

> > Is is reasonable for configure to check if newlib is installed, and if
> > not, resort to the generic interface?
>
> Checking whether it's /installed/ isn't reasonable, because we may be
> building newlib in the same tree as libstdc++-v3, at the same time.
> I do this, and libstdc++-v3 gets built before newlib.

I believe libstdc++ already cannot even be configured properly without at 
least the target system headers present - because you've got be to able to 
run at least xgcc -c for configure to check anything. Without complete C 
library headers libstc++ certainly won't compile.

I've done a patch, it may not be submittable as such, but here it it for 
discussion purposes. Feedback appreciated.

Is does two things:

1) Attempts a compilaton of the things libstdc++ needs to use the 
config/os/newline, - if is fails use 
2) Moves the debug message of os_include_dir to after the final modification 
of it - stops configure telling me lies.

Index: aclocal.m4
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/aclocal.m4,v
retrieving revision 1.214
diff -u -r1.214 aclocal.m4
--- aclocal.m4	16 May 2002 17:43:01 -0000	1.214
+++ aclocal.m4	28 May 2002 23:54:56 -0000
@@ -879,8 +879,6 @@
 dnl GLIBCPP_CHECK_TARGET
 AC_DEFUN(GLIBCPP_CHECK_TARGET, [
     . [$]{glibcpp_basedir}/configure.target
-    AC_MSG_RESULT(CPU config directory is $cpu_include_dir)
-    AC_MSG_RESULT(OS config directory is $os_include_dir)
 ]) 
Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.in,v
retrieving revision 1.92
diff -u -r1.92 configure.in
--- configure.in	23 May 2002 16:08:46 -0000	1.92
+++ configure.in	28 May 2002 23:55:19 -0000
@@ -162,7 +162,10 @@
       os_include_dir="config/os/windiss"
       ;;
     *)
-      os_include_dir="config/os/newlib"
+      AC_TRY_COMPILE([#include <ctype.h>],
+            [int i = _U|_X|_B|_C|_P|_N|_L|_S;char *x=_ctype_;], 
+            os_include_dir="config/os/newlib",
+            os_include_dir="config/os/generic");
       AC_DEFINE(HAVE_HYPOT)
       ;;
   esac
@@ -300,6 +303,9 @@
   # Establish limits on memory usage during 'make check'
   GLIBCPP_CONFIGURE_TESTSUITE
 fi
+
+AC_MSG_RESULT(CPU config directory is $cpu_include_dir)
+AC_MSG_RESULT(OS config directory is $os_include_dir)
 
 # This depends on the possibly-skipped linker test above.
 GLIBCPP_ENABLE_SYMVERS([yes])