[Python-Dev] Problems with Python's default dlopen flags

[David Abrahams]

----- Original Message -----
From: "Martin v. Loewis" <martin@v.loewis.de>

> > > That explains a lot of things indeed. It doesn't explain why the
> > > exception handling on Linux fails (that should still work fine even
> > > with two separate copy of each typeinfo object, IMO),
> >
> > Not the way I read http://gcc.gnu.org/faq.html#dso.
> > Am I missing something? If an exception is thrown from ext1 -> ext2 and
> > they're not sharing symbols, there will be distinct copies of all
> > typeinfo objects used in the two modules, and the address comparisons
> > used to determine whether a catch clause matches ought to fail, no?
>
> Right. However, address comparisons are used only in gcc 3.0; gcc 2.95
> and earlier used string comparisons, and gcc 3.1 will use string
> comparisons again.

That's interesting information! I wouldn't have guessed, myself, that
address comparison was a huge speed benefit in real applications anyway.

> I was assuming that Ralf used gcc 2.95 to build the
> binaries.

No, he gave up up on 2.95.x a while back because the EH was too buggy.
Boost.Python v1 (which he's been using) relies more heavily than it
probably should on the EH mechanism.

> As Tim explains, if that was the cause, you'ld have a systematic error
> (failure every time). If the failure is only sometimes, it must be
> something else.
>
> > I don't think Ralf is explicitly using any non-const global objects or
> > explicitly relying on on object identity across extension modules, so
> > it's hard to imagine that this is at play.
>
> Are you sure there are no objects of static storage duration in Boost?

No, only that there are none which need to be shared across modules.
Boost.Python v1 can also be built as a static library (even on Windows,
where sharing is explicit), and it works just fine.

> It doesn't matter whether he uses them "explicitly": if he calls
> functions that use them, the object being used depends on which DSO
> the caller is in. With RTLD_GLOBAL, all calls go to one of the DSOs
> (independent from caller), thus a single and consistent set of global
> objects is used.

Yes, I understand. Having a sense of Ralf's application, it seems possible
but unlikely to me that this is the case.

-Dave