[C++-sig] Odd dlopen behavior

[Niall Douglas]

On 30 Jan 2012 at 1:21, Davidson, Josh wrote:

> Similar behavior, but now the storage import is FUBAR.  Does anyone
> understand what is going on here? 
> 
> I'm using x64 Python 2.6.6 on x64 RHEL 6.  Gcc version 4.4.6.

It's never popular for me to say this, but shared libraries really 
aren't implemented well in ELF. It's always more unnecessary work 
there due to its bad design.

Have you applied symbol visibility as per 
http://www.nedprod.com/programs/gccvisibility.html? It should be a 
cinch if you already have windows support in there.

On the wider issue, BPL has no concept of DLL/SO type ownership, so 
if DLL A defines a class Foo and DLL B defines a class Foo with a 
completely different definition, all BPL can do is complain when it 
sees the type's registration code being duplicated without knowing if 
it's serious or not. Needless to say, any binary generated here can't 
work reliably unless one disables one or the other of class Foo.

Now regarding your issue, Py++ has to make the assumption that thunk 
code must be generated for each type for each module output even 
though those can't be combined without runtime warnings. If you've 
implemented the GCC visibility stuff above and you still have a 
problem, you need to start marking the clashing symbols as weak or 
inline so GNU ld elides the duplicates at runtime.

I'm sure Py++ can insert the required markup automagically - Roman 
might be able to help here.

If that isn't a runner, start chopping out sections of API mirrored 
into the Python space, or if you need that section then break your 
common DLL/SO into its own python module and have that be imported by 
the modules using that common DLL/SO. Remember that you can split a 
large DLL/SO in multiple Python module representations as needed.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.