Re: Minimal GCC/Linux shared lib + EH bug example

["David Abrahams" <david dot abrahams at rcn dot com>]

For the c++std-ext recipients, just added: previous messages in this
thread, which concerns the semantics of shared libraries w.r.t.
exception-handling and other C++ features which require "vague linkage",
can be found here:
http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html
http://gcc.gnu.org/ml/gcc/2002-05/msg00869.html
http://gcc.gnu.org/ml/gcc/2002-05/msg00873.html

----- Original Message -----
From: "Jason Merrill" <jason@redhat.com>

> > What I'd prefer to happen is that in step 4, the loader would use the
> > existing definition for any loaded symbol which is defined in or used
by
> > lib2's immediate dependencies. That would nicely model the concept that
> > lib2.so is sharing globally with X.so but not with lib1.so, and it
seems
> > like the "right" solution.
>
> I noticed that the readme says that the test passes on Solaris.  Does it
> provide these semantics?  How about SCO?  Anyone?

The test as written doesn't really tell us the answer since it uses EH and
any implementation can make it a non-issue by comparing type_info::name()
strings instead of addresses. The test could easily be modified the so it
looks at the address of a class template's static data member, of course.

> > However, for my application I'd be content if EH was just comparing the
> > type_info::name() strings, as Martin von Loewis stated was the case in
> > 2.95.x and again in 3.1:
> > http://aspn.activestate.com/ASPN/Mail/Message/1191899 [This statement
> > appears to be contradicted empirically, though: Ralf reports similar
> > problems with GCC 3.1 - GNATS id 6629].
>
> Yes, 3.1 still relies on pointer comparison.
>
> I find this testcase somewhat persuasive, as the offending dlopen call is
> not in the C++ code.  What do others think?

I guess you /know/ what I think: I just want it to work ;-)

I'd also like to point out what I think is a fundamental difference in the
Windows and Linux models for shared libraries: in the Windows model,
sharing has a "direction" but in the Linux model the direction is
determined by who got there first. So, for example, in the Windows model
when lib.dll and lib2.dll are loaded there are certain symbols which come
in from their dependency, X.dll, because they're explicitly imported. It's
the fact that the libraries explicitly "pull" symbols from their
dependencies that makes the model work. In the Linux model, it appears that
lib1.so and lib2.so essentially load everything they've got and "push"
their symbols onto X.so. In the case we're looking at, the dependency may
already be loaded so the push might leave us with two copies of some
symbols in the lib<N>.so/X.so relationship.

-Dave