Andrew Gillham writes:
> Aaron Brown writes:
>> 
>> Has anyone had trouble with g++ on the sparc port (specifically the Sun4m)
>> or any other port recently?  This simple program:
>> 
> [...]
>> 
>> segfaults when run.  (test is non-empty).  I built libg++ and libstdc++ with
>> debugging symbols, and as far as I can tell, the "this" pointer is getting
>> trashed somewhere inside istream::get().  It starts out as a nice stack
>> address (0xf7fff548 or something) and then turns into 0x4000xxxx by the
>> time it gets to ipfx1 inside istream::get(). 
> 
> This program runs fine for me on: (Sparc LX, sun4m)
> NetBSD logrus 1.1B NetBSD 1.1B (LOGRUS) #1: Mon Apr 29 15:26:21 EDT 1996 
> gillhaa@logrus:/usr/src/sys/arch/sparc/compile/LOGRUS sparc

It crashed for me on: (SPARCstation 2, sun4m)
NetBSD netbsd4me 1.1B NetBSD 1.1B (GENERIC_SCSI3) #10: Thu Apr 11 16:02:07
MET DST 1996     pk@neon:/usr/src/sys/arch/sparc/compile/GENERIC_SCSI3 sparc

i.e., pk's April 12th SPARC 1.1B snapshot.

>> This program runs on NetBSD-1.1/i386 just fine. Has anyone seen similar
>> strange behavior and/or can anyone else reproduce this? (I'm trying to
>> find out if it is in some bizarre way a sun4m port bug). This is with the
>> most current libg++/g++/gcc/libc/etc (all built yesterday).
> 
> Hmm, maybe *I* am being clueless, but does the new 'make includes' stuff
> actually install the g++ headers correctly?  I ended up having to manually
> copy the iostream.h/fstream.h (and dependancies) to /usr/include/g++.
> Maybe you don't have the latest headers installed?

I think you (Andrew) hit the nail on the head.  There's a raft of old leftover
g++ headers in my /usr/include/g++ ("Apr 11" is the date on all files installed
from the snapshot):

netbsd4me:1:150 % ls -lt /usr/include/g++ | egrep -v "Apr 11"
total 791
drwxr-xr-x  2 bin  bin    2560 May  1 03:25 gen/
-rw-r--r--  1 bin  bin    5904 Oct 22  1994 values.h
-rw-r--r--  1 bin  bin   10040 Oct 22  1994 regex.h
-rw-r--r--  1 bin  bin    1532 Oct 22  1994 _G_config.h
-rw-r--r--  1 bin  bin    4188 Oct 22  1994 strstream.h
-rw-r--r--  1 bin  bin   17235 Oct 22  1994 streambuf.h
-rw-r--r--  1 bin  bin    1554 Oct 22  1994 stdiostream.h
-rw-r--r--  1 bin  bin     828 Oct 22  1994 stream.h
-rw-r--r--  1 bin  bin    1251 Oct 22  1994 procbuf.h
-rw-r--r--  1 bin  bin    5117 Oct 22  1994 parsestream.h
-rw-r--r--  1 bin  bin    2276 Oct 22  1994 ioprivate.h
-rw-r--r--  1 bin  bin    8159 Oct 22  1994 iostream.h
-rw-r--r--  1 bin  bin    4693 Oct 22  1994 iomanip.h
-rw-r--r--  1 bin  bin    2543 Oct 22  1994 indstream.h
-rw-r--r--  1 bin  bin    2657 Oct 22  1994 fstream.h
-rw-r--r--  1 bin  bin    1137 Oct 22  1994 floatio.h
-rw-r--r--  1 bin  bin    6485 Oct 22  1994 editbuf.h
-rw-r--r--  1 bin  bin    1568 Oct 22  1994 SFile.h
-rw-r--r--  1 bin  bin    2972 Oct 22  1994 PlotFile.h

All of these have newer counterparts down in /usr/src/gnu/lib/libg++/libio et
al.  Which of course brings us right back to John C. Hayward's question
"Why are libio & libiostream commented out in /usr/src/gnu/lib/libg++/Makefile"
(-:

	- Greg