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.

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.)

Fwiw, my dynamic loading example works out of the box in another OS I tried,
here you see why:

[drochner@zel568 dltest]$ c++ -v -shared -o virt.so virt.o
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/collect2 -m elf_i386 -shared -o 
vir
t.so /usr/lib/crti.o /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/crtbeginS.o 
-L/
usr/lib/gcc-lib/i586-mandrake-linux/2.95.2 -L/usr/i586-mandrake-linux/lib 
virt.o
 -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/crten
d
S.o /usr/lib/crtn.o

best regards
Matthias