Re: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

[Florian Weimer <fweimer at redhat dot com>]

* David Kilroy:

>> Szabolcs Nagy
>> 
>> On 21/10/2019 15:21, Florian Weimer wrote:
>> > * David Kilroy:
>> >> I suspect that this wouldn't work in my use case though. External
>> >> projects link against the filter object we produce, and don't know
>> >> about the filtee (which is effectively an implementation detail).
>> >> Different suppliers can also supply the library (which may or may not
>> >> be a filter object), so having the external project link the library
>> differently based on implementation is...
>> >> suboptimal.
>> >
>> > If you currently use a symbolic link for the .so link object, it
>> > should be easy enough to replace that with the script.  If the link
>> > time DSO is stored under its soname, then of course this does not
>> > work, but you wouldn't be able to transparently inject the filter
>> > either, so that doesn't seem to be your scenario.
>> 
>> linker script only works at static link time, not for dlopen.
>
> This did confuse me. I think you're proposing something like:
>
> Implementation library, libimpl.so
> Filter libraries, libapi_a.so, libapi_b.so
>
> libimpl.so       => libimpl.so.2

This symbolic link should not be there if there is no expectation that
applications link directly with -limpl.

> libimpl.so.2     => libimpl.so.2.3.4
> libimpl.so.2.3.4    (the actual implementation, soname set to
>                      libimpl.so.2)
>
> libapi_a.so          (stub with api selected using version script,
>                       and soname set to libapi_a.so.1)
> libapi_a.so.1     => libimpl.so
> libapi_a.so.1.2.2 => libimpl.so

The two symbolic links above should probably go straight to
libimpl.so.2.3.4 at run time, so that libimpl.so can be made optional.

> libapi_b.so          (stub with api selected using version script,
>                       and soname set to libapi_b.so.3)
> libapi_b.so.3     => libimpl.so
> libapi_b.so.3.4.5 => libimpl.so

Likewise here.

> I think this works when the application links, and the resulting
> applications would run.
>
> In the dlopen case, if you're in control of the applications, you can
> make them all open the right link library (libapi_x.so.n). This isn't
> possible if there are other implementations of the library that the
> application can link against (which may have different versions). In
> that case the application must dlopen libapi_x.so, which will get the
> stub library with this layout.

The application must dlopen based on soname, which is either
libapi_a.so.1 or libapi_b.so.3, and that will load libimpl.so.2.3.4.  It
must not use the link-time symbolic links, otherwise it risks picking up
an incompatible library with a different ABI.  This is a general rule,
it is not related to this setup.

> If this is what you intended, I think my main objection is that it's
> rather unexpected...

Why is it unexpected?

Thanks,
Florian