Hi, I filed a bug report about g++ shared libraries not working,
However being impatient, I have looked into the problem myself...

Here for those interested is what I have found... (this is my first
look inside shared library mechanisms so if I've got anything wrong
I would be grateful to find out).

for g++, ld builds global constructor tables CTOR_LIST and destructor
 DTOR_LIST.

the object file /lib/c++rt0.o contains two functions .init .fini which
when linked with the shared object code use CTOR_LIST & DTOR_LIST to
initialise global objects.

If a shared library uses global objects (Which is not_philosophically_sound,
but hey, i'm not about to re-write everyone else's code...) an attempt to
access that object before its constructor is called will almost certainly
seg-fault.

ld.so is supposed to call an init and fini routine in a shared library to
give it a chance to call constructors etc, however looking at ld.so source
reveals it expects these routines to be called _init and _fini...

Erm .init != _init: so either a new c++rt0.o (with _init's) is needed
or a new ld.so (looks for .init) or ld.so is doing something cleverer
than I thought and .init is a special breed of symbol or something.

almost a workaround...
----------------------

This almost worked as a workaround...

mv /usr/lib/c++rt0.o /usr/lib/c++rt0.old
sed </usr/lib/c++rt0.old -e 's/\.init/_init/g' | sed -e 's/\.fini/_fini/g' >/usr/lib/c++rt0.o

Now this worked for a toy library linked with an test app. But when I
tried it with multiple c++ libs it still seg-faulted... Anyway its a complete
hack and am probably lucky that it even worked for a simple test case.

So...

If ld.so is correct (which being the new ld.elf_so it probably is)
the question is where do I get the correct /usr/lib/c++rt0.o

Or am I barking up the wrong tree?

Best Regards,

	Keean Schupke.

Computer Support Group.
Dept. of Electrical & Electronic Engineering,
Imperial College,
London.