more problems using lang/gcc33 or lang/gcc34 for world & kernel & some ports

To add to the problems mentioned previously in this thread. 

For this below, I'm using solely lang/gcc33 (aka gcc334).

The buildworld with NO_DYNAMICROOT=yes set in /etc/make.conf
did help a bit mentioned previously.  At least the shells
found their symbols, so the system comes up to a ttyv fine. 
Starting a plain KDE/X11 environment works, too.

Compiling world with NO_DYNAMICROOT=yes did _not_ help with
the "undeclared MD5_*" problems when it came across libopie
and others as mentioned previously.

Yesterday I removed NO_DYNAMICROOT=yes so we could again see
how gcc334 does things that way.  I also applied CTM buckets
thru late yesterday evening (CDT).  Now it breaks building
libstdc++ as shown here:
[...]
===> gnu/lib/libstdc++
/usr/local/bin/g++33  -march=pentium2 -pipe -O2  -march=pentium2 -pipe -O2 -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /src/contrib/libstdc++/src/bitset.cc
[...]
/usr/local/bin/gcc33 -fpic -DPIC  -march=pentium2 -pipe -O2  -march=pentium2 -pipe -O2 -march=pentium2 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/src/gnu/lib/libstdc++ -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/src/gnu/lib/libstdc++/../../../contrib/gcc  -c /src/contrib/gcc/cp-demangle.c -o cp-demangle.So
/usr/local/bin/gcc33 -fpic -DPIC  -march=pentium2 -pipe -O2  -march=pentium2 -pipe -O2 -march=pentium2 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/src/gnu/lib/libstdc++ -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/src/gnu/lib/libstdc++/../../../contrib/gcc  -c /src/contrib/gcc/dyn-string.c -o dyn-string.So
building shared library libstdc++.so.4
/usr/obj/src/i386/usr/bin/ld: libstdc++.so.4: undefined versioned symbol name std::time_put_w_at__at_GLIBCPP_3.2
/usr/obj/src/i386/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
*** Error code 1 (continuing)
`all' not remade because of errors.
===> gnu/lib/libsupc++
[...]

Also, for some reason, after installing this bad build,
anything using /lib/libc.so.5 started having missing
symbols unrelated to what is shown above, and I can't
find a bad build of libc in this same buildworld log. 
The log _shows_ libc.so.5 & its relatives all compiled
and linked fine.  I did a rescue by copying libc.so.5
from a slightly old JPSNAP CD.

Could any of these glitches with gcc334 be a local
makefile problem?
Or would they be bugs with gcc334 itself?

If it is bugs with gcc334, can someone update the
lang/gcc33 port with a later snapshot, please?

Does anyone care that we try using a later gcc than
what is installed with 5-current world?  I feel
sooner or later we will be forced into using it.


  --  thx, Paul Seniura.