This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dlopen, RTLD_LOCAL and identically named libraries


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.

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


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

Is there a spec or documentation that describes the process for
RTLD_LOCAL and or SONAME handling?
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.

Cheers,
Mark

On Fri, Aug 29, 2014 at 4:17 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Thu, Aug 28, 2014 at 11:54 AM, Mark Boorer <markboo99@gmail.com> wrote:
>> I have a question regarding dlopen with RTLD_LOCAL and libraries with
>> identical names
>>
>> I have two versions of a library with the same filename in separate
>> directories, and I have two separate "plugins", each linking to one
>> version of the library.
>>
>> plugin1.so -> library1/library.so
>> plugin2.so -> library2/library.so
>
> OK. I assume both library.so's have the same SONAME.
>
>> The path to library.so is baked into the RPATH of each plugin, so when
>> ran independently, they each call the correct functions. However, when
>> I load both plugins one after the other (with RTLD_NOW | RTLD_LOCAL) ,
>> only the first version of library.so is used.
>
> As expected.
>
> 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.
>
>> The behaviour is the same if the two versions of library.so share an
>> soname as well. It seems as though the basename of the library (or the
>> soname) is checked at a global level.
>> I would expect that behaviour if library.so was already linked in the
>> global scope, but in my case it is not.
>
> That's not how ELF loading works.
>
>> Is this the intended behaviour? I would have thought that RTLD_LOCAL
>> would start the library search afresh.
>
> It does, but only for plugin1.so, not for the dependencies.
>
>> Any help/advice would be greatly appreciated :)
>
> 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.
>
> I apologize in advance that this is not documented in either the glibc
> manual or the linux kernel man pages. I'll try to correct that.
>
> Cheers,
> Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]