Ok, well I did figure out the discrepancy between these extensions and previous extensions that have been built that required setting RTLD_GLOBAL. What I'm doing for these extensions is instead of building in all of the original C++ code AND the Py++ generated code into the extension, I'm only building in the Py++ generated sources and linking an existing shared library containing the original C++ definitions. Is this non-standard or bad practice?
One issue with this is I'm now forced to deliver both the Python extension shared libraries and the original shared libraries. Not a huge deal, but it does add a little work on the deployment and maintenance end. 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. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
