Matthias Drochner wrote:
> 
> fvdl@wasabisystems.com said:
> > > What's the right way to deal with this - perhaps link in
> > > libgcc.a "whole-archive" into programs using dlopen(), or
> > > provide a shared libgcc?
> > I encountered this problem once, and fixed it by linking the shared
> > object that was to be dlopen-ed explicitly with -lgcc.
> 
> After investigating a bit, I'd say linking the shared object against
> libgcc is the right solution. After all, the main program is not
> necessarily made by a gcc toolchain at all, so one can't expect it
> to include support for all kinds of objects one could choose to
> load dynamically. If the object to be loaded needs some strange
> runtime support, it has to make sure that it is present.

I would agree that linking in libgcc is the right thing to do. However,
libgcc is not available as a shared library or even compiled -fPIC.
LIBGCC_SPEC was changed by Charles recently to specificaly not include
libgcc.a when gcc is invoked with -shared 

> However, the toolchain generating the shared object should take
> care of it. Our gcc does already, albeit incompletely:
> 
> bash-2.04$ c++ -v -shared -o virt.so virt.o
> Using builtin specs.
> gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
>  /usr/libexec/collect2 -m elf_i386 -shared -o virt.so /usr/lib/crtbeginS.o -L/u
> sr/libexec virt.o -lstdc++ -lm /usr/lib/crtendS.o
> 
> libstdc++ is already included, adding -lgcc should be simple:-)
> (-lgcc should be linked in for plain C too because it contains some
> C runtime support too.)

As above this was specifically removed. I have asked what the best
solution is here but the toolchain experts remain strangely quiet in a
public forum.

FreeBSD seems to have a libgcc_pic.a and OpenBSD has libgcc always
compiled -fPIC. There seems to be some magic used by Linux systems that
I don't understand.

Still confused,
Nick