If a shared library is linked to another than any attempts from the first library to promote the symbols of the second library to RTLD_GLOBAL does not work [via dlopen("libsecond.so", RTLD_NOLOAD|RTLD_GLOBAL), or using RTLD_LAZY or RTLD_NOW].

This is known to affect devel/kdebindings4-python-pykde4.

This is not a problem under Linux (i.e. linux exhibits expected behaviour).

Fix: There is only a work-around that may not work in all situations:
Promote the first libraries symbols to RTLD_GLOBAL.  This, however, I think is overly broad and deviates from established behaviour (under Linux).  

In the example attached this amounts to:
dlopen("libplugin.so", RTLD_NOLOAD | RTLD_GLOBAL)
where libplugin.so is the first library.  

Patch attached with submission follows:
How-To-Repeat: [skip to bottom for coded example]

Have a shared library that is linked (at compile time) to a second library then have the second library load a third that requires symbols from the second but does not declare its dependency on the second library [e.g. libpython and lib/python26/lib-dynload/*].  

If the second library is loaded (without being linked) with RTLD_GLOBAL then all is well.  

See attached for rtld_global.shar.  Extract content and run:
# make  *
# make -DTRIGGER **

This runs two tests.  The first test is the first library that dlopen's the second library (it should run fine).  The second test is the first library that is linked to the second library and attempts to promote the second libraries symbols to RTLD_GLOBAL.  See below:

* Runs with work-around (see Fix below).  This works
** Runs without work-around [aka dlopen("libmaster.so", RTLD_NOW | RTLD_GLOBAL)] with 'libmaster.so' being the second library.  This does not work.