This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Undefined symbol __gxx_personality_sj0 (data) from stdexcept.o
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: Undefined symbol __gxx_personality_sj0 (data) from stdexcept.o
- From: law at redhat dot com
- Date: Thu, 17 May 2001 09:33:52 -0700
- cc: gcc-bugs at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <200105171550.LAA08030@hiauly1.hia.nrc.ca>you write:
> > > /usr/ccs/bin/ld: Unsatisfied symbols:
> > > __gxx_personality_sj0 (data)
> > >
> > > This is under hpux 10.20 with the 3.0 branch. This symbol comes from
> > > the stdexcept.o module in libstdc++. Note that the symbol is `data'.
> > > I believe that this should be a text symbol. This symbol reference
> > > is generated in cp/except.c.
> > Yea. Tracking this down is at the top of my gcc3 list for today. Most
> > likely we've got an incorrect or missing .import statement which in turn
> > causes the wrong symbol type to be used.
>
> Possibly, libsupc++/unwind-cxx.h needs to be included by stdexcept.cc.
> However, it does seem that the compiler shouldn't be generating a
> reference to a library function without an .import statement. I did
> look at the assembler output for stdexcept.cc and the only references
> to __gxx_personality_sj0 were in the code itself. For example,
>
> addil LR'__gxx_personality_sj0-$global$,%r27
> ldo RR'__gxx_personality_sj0-$global$(%r1),%r1
>
> There is no .import statementy.
Armed with John's investigative work, I've got a potential fix for this bug
that I'm beating on right now. Initial results look good (C++ code appears
to be working again :-)
jeff
jeff