Re: dlopen, RTLD_LOCAL and identically named libraries

["Carlos O'Donell" <carlos at redhat dot com>]

On 09/02/2014 02:59 PM, Mark Boorer wrote:
> EDIT: forgot to forward this to the main mailing list.
> 
>> OK. I assume both library.so's have the same SONAME.
> 
> In my particular case they did not have an SONAME at all, but the
> behaviour was the same when they did have identical SONAMEs.

Distinct SONAMEs should cause *both* libraries to be loaded,
however, the first loaded library will always be used to resolve
symbols which are defined in both libraries since those definitions
are bound to first.

So even with distinct SONAMEs you have a global symbol collision
just like any other library might have with any other library in
the distribution or a 3rd part library.

I assume this is why it doesn't work for you.

>> You have told the OS, by using the same SONAME, that the libraries are
>> identical.
>> If the libraries are not identical then they should have distinct
>> SONAMEs since they are distinct libraries.
> 
> It's not so much that the libraries are identical, but they are
> different versions of the same library, and version2 exports some
> additional symbols.
> If version1 is the only one loaded, then any calls that require
> version2 will fail. But version2 functions in all cases where version1
> is required.
> Similar to the way libstdc++ works.
 
That's easy then, just make sure version2 is always loaded first.
Preload version2 if you can. ELF symbol resolution rules all boil
down to "the first library you load is the one you'll resolve to first."
 
>> Use dlmopen and LM_ID_NEWLM, and tell us how it goes. Those features
>> aren't all that well exercised, but should do what you want.
> 
> Unfortunately I often don't the control the source application calling
> dlopen. It's more that we sometimes have different plugins using
> similar libraries, or libraries compiled with different flags. One
> other place where I frequently encounter this issue is with python
> plugins.

OK, then that's out of the question.

> Is there a spec or documentation that describes the process for
> RTLD_LOCAL and or SONAME handling?

`man dlopen`, search RTLD_LOCAL, we work with the Linux Kernel man pages
project to keep the details updated.

SONAME handling isn't discussed anywhere in detail, but it should be
discussed in the glibc manual, but it isn't. Unix or Linux programming
books do cover this.

> To me it seems like quite a useful feature to be able to isolate two
> separately rpath'd libraries, regardless of soname, but I'd love to
> understand the deeper workings if such a thing violates POSIX
> compliance or something.

You can do some isolation without control of dlopen, and it was
implemented by Solaris and the spec is followed by GNU/Linux.

It is called DT_FLAGS_1. It is a set of flags set for the built DSO
that dictate in a per-DSO way how it should be loaded.

The DT_FLAGS_1 break down into:
#define DF_1_NOW        0x00000001      /* Set RTLD_NOW for this object.  */
#define DF_1_GLOBAL     0x00000002      /* Set RTLD_GLOBAL for this object.  */
#define DF_1_GROUP      0x00000004      /* Set RTLD_GROUP for this object.  */
#define DF_1_NODELETE   0x00000008      /* Set RTLD_NODELETE for this object.*/
#define DF_1_LOADFLTR   0x00000010      /* Trigger filtee loading at runtime.*/
#define DF_1_INITFIRST  0x00000020      /* Set RTLD_INITFIRST for this object*/
#define DF_1_NOOPEN     0x00000040      /* Set RTLD_NOOPEN for this object.  */
#define DF_1_ORIGIN     0x00000080      /* $ORIGIN must be handled.  */
#define DF_1_DIRECT     0x00000100      /* Direct binding enabled.  */
#define DF_1_TRANS      0x00000200
#define DF_1_INTERPOSE  0x00000400      /* Object is used to interpose.  */
#define DF_1_NODEFLIB   0x00000800      /* Ignore default lib search path.  */
#define DF_1_NODUMP     0x00001000      /* Object can't be dldump'ed.  */
#define DF_1_CONFALT    0x00002000      /* Configuration alternative created.*/
#define DF_1_ENDFILTEE  0x00004000      /* Filtee terminates filters search. */
#define DF_1_DISPRELDNE 0x00008000      /* Disp reloc applied at build time. */
#define DF_1_DISPRELPND 0x00010000      /* Disp reloc applied at run-time.  */
#define DF_1_NODIRECT   0x00020000      /* Object has no-direct binding. */
#define DF_1_IGNMULDEF  0x00040000
#define DF_1_NOKSYMS    0x00080000
#define DF_1_NOHDR      0x00100000
#define DF_1_EDITED     0x00200000      /* Object is modified after built.  */
#define DF_1_NORELOC    0x00400000
#define DF_1_SYMINTPOSE 0x00800000      /* Object has individual interposers.  */
#define DF_1_GLOBAUDIT  0x01000000      /* Global auditing required.  */
#define DF_1_SINGLETON  0x02000000      /* Singleton symbols are used.  */

The option you want would be DF_1_GROUP.

http://docs.oracle.com/cd/E36784_01/html/E36874/dlopen-3c.html#REFMAN3Adlopen-3c
~~~
RTLD_GROUP

    Only symbols from the associated group are made available for relocation. A group is established from the defined object and all the dependencies of that object. A group must be completely self-contained. All dependency relationships between the members of the group must be sufficient to satisfy the relocation requirements of each object that defines the group.
~~~

Also an option would be direct bindings:
http://docs.oracle.com/cd/E36784_01/html/E36857/aehzq.html#OSLLGaehzq

These are "advanced" features that glibc doesn't yet have because nobody has
been interested in them or needed them.

Cheers,
Carlos.