[C++-sig] EXTERNAL: Re: Odd dlopen behavior

[Niall Douglas]

On 31 Jan 2012 at 16:44, Davidson, Josh wrote:

> 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?  

The big problem with shared objects exporting lots of symbols was 
that the Linux runtime shared object linker used to have O(N^3) 
complexity. As a result, every time you ran a program linking to a 
ginormous shared object you'd get a pause of several seconds as it 
bound the symbols.

Now, some years ago with KDE and OpenOffice taking forever to load, 
some eyeballs were turned onto this problem and I know they were 
going to get it down to O(N^2). There was speak of replacing bits 
with O(N), but it would introduce ABI compat problems among other 
things. Another angle was making it use multiple cores. My attention 
ended up moving elsewhere so I have no idea what has happened since. 
It could still be O(N^2), it could be O(N) or somewhere in between.

> 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 systems with sane DLL designs like Windows and Mac OS X, you'd 
generally keep the Python bindings separate from the library being 
bound as it's cleaner and more self-contained. You can also issue 
smaller self-container ABI compatible releases as hotfixes etc etc.

On the insanity that is ELF, generally you can make inter-SO problems 
go away by linking everything into a ginormous monolithic SO. However 
you used to get that O(N^3)/O(N^2) problem I mentioned and maybe you 
still do. So, sometimes you just have to get your hands dirty and 
start with hack scripts which post-process the SOs to make their 
symbol tables sane, or write your own SO loader and binder 
implementation using dlopen() et al and bypass the system linker 
altogether :)

Sadly the ISO standards work to enforce sanity in shared libraries 
across all platforms got dropped from C11 and C++11, but I certainly 
will try to push that forward again for C11 TR1 along with a few 
other items on my shopping list (I'm the ISO SC22 convenor for 
Ireland, though Ireland is only an observer). The problem, as always, 
is a lack of sponsorship or funding by anyone who cares enough to 
have the problem fixed properly - and it is a difficult problem to 
get correct. In the end, as much as these problems are annoying and 
cost time to people like you, the cost of fixing them isn't seen as 
business relevant by those with the resources.

HTH,
Niall

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