On Sun, 15 Dec 1996, Paul Boven wrote:
> On the intel, the c++-virtual-classes are defined as being in the text-
> segnent, while on the sparc these same symbols (from the same sourcecode)
> are defined as data-segment. I find this rather suspect, and I wonder if
> I might have found a bug in the g++ shipped with NetBSD-1.2 and current,
> with the sparc, that is.
> 
> I assume that being in the wrong segment would be a reason for the linker
> to complain about these symbols, am I right? (undefined symbol __vt$t6SLList..
> referenced from text segment)

I found this comment in the file gcc/arch/sparc/sparc.h
/* This forces all variables and constants to the data section when PIC.
   This is because the SunOS 4 shared library scheme thinks everything in
   text is a function, and patches the address to point to a loader stub.*/
/* This is defined to zero for every system which doesn't use the a.out
   object file format.  */

...but we uses a.out, so I tried to define it as nonzero, and Ta-Da!
I'm now running Octave! (well running may be the wrong word... I compiled
without optimization, so my binary are >15 Megabytes, so it's a bit slow
on my machine with 16 Meg ram...  :)

I suggest that you add this line
#define SUNOS4_SHARED_LIBRARIES 1
to the top of the file 
   gcc/arch/sparc/netbsd.h
Observe that you must add this before the line
#include <sparc/sparc.h>

I haven't tested this gcc-patch on more programs than octave-1.91, so I
don't know if it breaks anything. I will investigate it more later, but
now I _really_ must do some homework in group representations...  :(

   /Krister