Three items from the bleeding edge

[Michael Vance <briareos at lokigames dot com>]

1) Using recent snapshots (say, 20001009), the link stage seems to be
creating very important libc variables inside my binary, such as
_IO_2_1_stdout_:

[michael@namaste build]$ nm tribes2-debug | grep "stdin"
08471c60 D _IO_2_1_stdin_
0840e984 R _IO_stdin_used
084b3834 B stdin@@GLIBC_2.0

When I run the binaries, any attempts to access these variables, say
using printf(), causes a segfault in a mutex_lock of NULL, and sure
enough the lock structure of stdout is 0x0. It is NULL before
__libc_start_main is called, AFAICT. Various heap checking tools
report everything being okay.

2) egcs-20001016 snapshot failed during build:

System compiler is egcs-1.1.2 for i686-pc-linux-gnu.

./congfigure --prefix=/usr/local/gcc-20001016 --enable-languages="c++"
make bootstrap

if [ -f ranlib ] || [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ; then ranlib libcpp.a ; else true ; fistage1/xgcc -Bstage1/ -B/usr/local/gcc-20001016/i686-pc-linux-gnu/bin/  -DIN_GCC    -O2 -g -O2 -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
 -DHAVE_CONFIG_H  -o cpp0 cppmain.o \
intl.o libcpp.a obstack.o        ../libiberty/libiberty.a
./xgcc -B./ -B/usr/local/gcc-20001016/i686-pc-linux-gnu/bin/ -isystem /usr/local/gcc-20001016/i686-pc-linux-gnu/include -dumpspecs > tmp-specs
mv tmp-specs specs
echo "int xxy_us_dummy;" >tmp-dum.c
./xgcc -B./ -B/usr/local/gcc-20001016/i686-pc-linux-gnu/bin/ -isystem /usr/local/gcc-20001016/i686-pc-linux-gnu/include -S tmp-dum.c
cc1: Internal error: Segmentation fault.
   Please submit a full bug report.
   See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [s-under] Error 1
make[2]: Leaving directory `/home/michael/gcc-build/gcc'
make[1]: *** [stage_c] Error 2
make[1]: Leaving directory `/home/michael/gcc-build/gcc'
make: *** [bootstrap] Error 2

Building 20001023 right now.

3) I'm getting a very disturbing RTTI crash with the RH7 gcc. I
understand this is unsupported, I'm simply asking for some advice in
investigating this:

(gdb) bt 4
#0  0x0 in ?? ()
#1  0x83686ea in __user_type_info::dyncast (this=0x857e450, boff=0, 
    target=@0x857e450, objptr=0x86d0cb8, subtype=@0x857e3ac, subptr=0x86d0cb8)
#2  0x8369947 in __dynamic_cast_2 (
    from=0x839fd60 <DecalManager type_info function>, 
    to=0x839fd60 <DecalManager type_info function>, boff=0, address=0x86d0cb8, 
    sub=0x839e8f0 <SceneObject type_info function>, subptr=0x86d0cb8)
#3  0x81a9bb6 in SceneGraph::addObjectToScene (this=0x86caa40, obj=0x86d0cb8)
    at sceneGraph/sceneGraph.cc:403
(More stack frames follow...)
(gdb) up
#1  0x83686ea in __user_type_info::dyncast (this=0x857e450, boff=0, 
    target=@0x857e450, objptr=0x86d0cb8, subtype=@0x857e3ac, subptr=0x86d0cb8)
(gdb) up
#2  0x8369947 in __dynamic_cast_2 (
    from=0x839fd60 <DecalManager type_info function>, 
    to=0x839fd60 <DecalManager type_info function>, boff=0, address=0x86d0cb8, 
    sub=0x839e8f0 <SceneObject type_info function>, subptr=0x86d0cb8)
(gdb) up
#3  0x81a9bb6 in SceneGraph::addObjectToScene (this=0x86caa40, obj=0x86d0cb8)
    at sceneGraph/sceneGraph.cc:403
403           if (dynamic_cast<DecalManager*>(obj) != NULL) {
(gdb) p obj
$2 = (SceneObject *) 0x86d0cb8
(gdb) 

Oddly, if I build *and* link these object files with gcc-20001009, it
works fine, but if I build them with 20001009 and link with gcc-rh7,
it also segfaults. Various heap verification tools tell me everything
is okay.

Any commentary is appreciated.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire