RE: can't catch exceptions from inside dynamically loaded object

[sgk at happysize dot co dot jp]

I have experienced that the same memory problem occurs on
sparc-sun-solaris2.5.1, sparc-sun-solaris2.6, i586-pc-solaris2.6 and
i586-pc-linux-gnu platforms when linking without "-export-dynamic"
option.

Shigeru Kanemoto
HappySize, Inc.

----------------Original message as follows----------------
From: Paul Forgey [mailto:paulf@aphrodite.com]
Sent: Sunday, January 31, 1999 5:07 PM
To: sgk@happysize.co.jp; egcs-bugs@cygnus.com
Subject: Re: can't catch exceptions from inside dynamically loaded
object

What you point out makes perfect sense.  As a win32 developer also, I am
quite aware of some of the gotchas of dynamic libraries.  Win32 has a
similar gotcha, but there is no equivilent to the --export-dynamic.

Consider a main application using a DLL, but both exe and dll are linked
to
have the crt in a dll.  In this case, and only in this case, may the dll
and
exe free() or delete memory malloc()'d or new'd in the other, and dittio
for
catch()ing exceptions throw()n in the other.

Here's where the egcs solaris behavior becomes a bug, but I'm not
certain if
it's a solvable bug.

My .so is statically linked against libstd++ (I ln'd a libstdc++-ar so I
can
have the libstdc++ static and not loose dynamic linkage against other
things, like libpthread, which needs one and only one instance).  So the
dynamic library has it's own version of any global objects which need to
be
constructed at load time.  Solaris does not seem to have a shared
library
function which gets called at load time (like via dlopen()).

This is how the win32 senario is able to work.  If my exe was linked
against
the dll, and the dll is staically linked against the crt, then the dll
becomes it's own little island (as far as crt objects are concerned),
but
global initialization of the dll's crt is able to happen because of
DllMain(), which gets called when the process starts, exists, thread
start,
thread exit.

One possible workaround would be to call a crtmainstartup() (or whatever
it
is that gets called by the linker or kernel), but this could have very
unintended side affects.

I think we can conclude a few things:

when building the dynamic library, one option would be to NOT link in
libstdc++ at all, which would require the main application be using
libstd++
as a shared object
which means the application will have already initialized it, and the
.so
being loaded will be using the same copy (which is why you don't put in
the
import linkage when building it; you want only one copy process-wide)
which means things will work just fine (and they do according to my
tests)

But if the shared object is linking against a library needing static
initialization, then the shared object must call it's initializer.