Installing gcc v2.95.2 with libstdc++-v3 (or 2?)

["James F. Carter" <jimc at math dot ucla dot edu>]

Versions:  
    gcc v2.95.2 as released 1999-10-24 
	(ftp.freesoftware.com/pub/gnu/gcc/gcc-2.95.2.tar.gz dated
1999-10-25)
    libstdc++ v2.10.0 (per Makefile.in) dated 1999-04-02 
	(included with gcc)
Context: sparc-sun-solaris2.5 and 2.6, Gnu make

I have the following problems installing gcc v2.95.2.  Since the
relevant sources and scripts are in the gcc release, I'm posting to
gcc-help, but since the issues appear to be with libstdc++ I'm
cross-posting to that list.

    1.  Having created and changed to a build directory $objdir, I execute 

    $srcdir/configure  --prefix /usr/local/gcc/$vers --enable-shared \
	--enable-languages=c++,f77,java 

It configures gcc (and its subdirectories), libiberty and texinfo, but
does not configure libio or libstdc++, and the toplevel Makefile does
not do those directories.  From the source to `configure` I'm not able
to figure out the --with switches, contingencies, etc. that would cause
those directories to be configured coordinately with gcc.  If I'm
reading the source correctly, they *should* be recognized.  My
alternative seems to be to figure out how to suppress namespaces in gcc
and to build libio and libstdc++ separately.  Can anyone help me get
`configure` to behave?

    2.  As compiled, g++ expects libstdc++ v3, but the distributed
package is v2, neither of which got installed.  What do I do, get a
development snapshot of v3 or jigger the g++ specs file to use v2 by
default?  Or lie and make a symbolic link from g++-3 to g++-2?  Verbose
output: the third from last line is what leads me to believe that
version 3 is sought.

[root bamboo /m3/Gnu/gcc-obj 40] g++ -v hello.C
/usr/local/bin/g++: exec /usr/local/gcc/2.95.2/bin/g++ -v hello.C 
Reading specs from
/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5/2.95.2/cpp
-lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus
-Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__
-D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix
-Asystem(unix) -Asystem(svr4) -D__EXCEPTIONS -D__GCC_NEW_VARARGS__
-Acpu(sparc) -Amachine(sparc) hello.C /var/tmp/ccTgN0cY.ii
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include

/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5/2.95.2/../../../../sparc-sun-solaris2.5/include
 /usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:

/usr/local/gcc/2.95.2/lib/gcc-lib/sparc-sun-solaris2.5/2.95.2/../../../../include/g++-3
End of omitted list.
hello.C:1: iostream.h: No such file or directory

    3.  We intend to use this gcc/g++ as a production compiler for our
students and faculty.  However, going over the Completion Checklist
dated 1999-05-18 (http://sources.redhat.com/libstdc++/17_intro/CHECKLIST)
I see that most functions in libstdc++ are in T status (implemented pending
tests) or V status (passed test suite), but quite a number are S (stub
only) and X (partially implemented or known buggy).  Incomplete
implementation of the "new" features described in ISO 14882 but not in the
ARM is not of too much concern, but I have qualms about giving non-gurus a
library with significant historic features that are broken, like va_end
etc. and setjmp, even though they're uncommon.  What is your opinion about
using this release in a production environment in which ARM-compliant code
has to work?

    4.  Good news for a change: we have tcl/tk 8.0 and thus are unable
to compile dejagnu-1.3 (which uses tk 7.5 symbols), but I ran many of the
tests from egcs-tests-1.1.2.tar.gz, scoring them manually.  gcc failed
only on its one Known Bug (if a structure that has a volatile data
member is declared in a  parameter list and has the register keyword,
the keyword is treated as an error rather than being ignored).  g++ test
cases (that I ran) that didn't include header files were all compiled /
executed / rejected correctly.

James F. Carter        Voice 310 825 2897	FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Internet: jimc@math.ucla.edu (finger for PGP key)
UUCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc