Re: [Gábor Gombás] Bug#564566: libkadm5clnt7: SONAME conflict with Heimdal

[Jeffrey Hutzelman]

--On Monday, January 11, 2010 01:14:59 PM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> On Mon, Jan 11, 2010 at 01:18:45PM -0500, Tom Yu wrote:
>> Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> > I believe the Solaris RTLD indexes a running process' link map by
>> > SONAME.  If two objects have the same SONAME then only one will be
>> > loaded, regardless of -B group/local or RTLD_GROUP/LOCAL use.
>>
>> So the RTLD doesn't index by device+inode, etc.?
>
> I've heard back from the linker folks:
>
>| The SONAME is a convenience for recording a dependency by
>| a name, no matter how ld(1) found the object.
>|
>| But, ld.so.1 thinks of objects by dev/inode.  Thus you can
>| have two different libfoo's, presumably with the same SONAME,
>| in different dirs, and you can bring both of them into a process.
>|
>| Note that direct bindings allows different objects to bind to
>| each instance.  RTLD_GROUP is a poor mans direct binding model :-)
>| Without direct bindings, and given each object exports the same
>| interfaces, the process would normally bind to the first instance
>| loaded as it would effectively interpose on the latter.
>
> In other words, if you take care (i.e., use -B direct, available only in
> Solaris), you can load two different objects with the same SONAME, but
> the default behavior is to load just one.  I think the Linux behavior
> matches the Solaris default (Linux does pre-linking instead of direct
> binding).

This requires a lot of effort, and possibly work on the part of the code 
doing the load and/or of whoever built the object(s) with the dependencies 
on whichever library has conflicting versions.  After all, if you're 
loading an object by soname, you're actually going to get the same object, 
unless you have some way for the search algorithm to operate differently 
for different loads from the same process.


FWIW, last I checked Linux (glibc) did not support RTLD_GROUP, but does 
support RTLD_DEEP_BIND, which is almost as good.

-- Jeff