Subject: Re: Bug in g++?
To: Paul Boven <firstname.lastname@example.org>
From: Krister Walfridsson <email@example.com>
Date: 12/16/1996 20:00:16
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
Observe that you must add this before the line
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... :(