Re: __register_frame_info problem on Alpha

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: Thu, 27 May 1999 11:45:16 +1000
> From: Geoff Keating <geoffk@ozemail.com.au>

> I propose the following glibc FAQ entry:
> 
> Q: When I run a program, it complains that __register_frame_info is
> undefined.  What's wrong?
> 
> A: 
...
> However, this _does not_ mean that applications should use the version
> defined in glibc.  They should always provide their own version, just
> as with all the other routines gcc defines (found in libgcc.a), and
> have glibc use that one.  This can be achieved by linking libgcc.a
> before libc, like `ld -o foo foo1.o foo2.o -lgcc -lc'.  Normally, you
> would use gcc or g++ to link and it should do this automatically if you
> just say 'gcc -o foo foo1.o foo2.o'.

Oh, I forgot to say that this is not supposed to be incompatible with
the current discussion in FAQ answer 2.8.  When that answer says

> For glibc 2.1, we've chosen to do it the other way around: libc.so
> explicitly provides the EH functions.  This is to prevent other shared
> libraries from doing it.

it is correct. Shared libraries should not provide the exception
handling routines, otherwise you have to put -lgcc before them too and
it's annoying to have to say
`ld -o foo foo1.o foo2.o -lgcc -lm -lgcc -lpam -lgcc -lc -lgcc'.

(`spam spam -lpam spam spam?' :-) ).

I also forgot to say that you can't throw exceptions between a plug-in
and the main program if the main program is linked statically to libc,
because the plug-in will be using a different copy of libc than the
main program.  The solution is to compile programs that use plug-ins
to use shared libc, which is what you'd usually do anyway.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>