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

[David Kilroy <David dot Kilroy at arm dot com>]

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

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

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.

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

> > I'm less clear how this all interacts with dlopen.  It seems that you
> > want a simple alias mechanism for dlopen.  In that case, a simple
> > symbolic link with the soname should work, and you don't need a
> > separate filter object, either.
> 
> the scenario is:
> 
> libA.so and libB.so export a set of symbols.  this is abi and there are
> multiple providers of libA.so and libB.so.
> 
> one provider wants to have a single libinternal.so that defines all the
> symbols of libA and libB as they share a lot of code.
> 
> (1) having libA.so and libB.so as "wrapper libraries" around libinternal.so
> with RTLD_NEXT would work, but that's less efficient because of the extra
> indirection,
> 
> (2) the filter library magic would avoid the wrapper.
> 
> (3) symlinking libA.so and libB.so to libinternal.so makes all symbols
> visible when either of them is loaded, polluting the link namespace.
> 
> (4) creating two copies of libinternal.so with different set of exported
> symbols would work just waste memory (assuming there is no internal global
> state that needs to be shared)
> 
> i think if link namespace pollution is ok then (3) is the best solution
> otherwise it's less clear, but probably (4) is most reliable.
>
> (libinternal.so is a video driver lib and libA, libB, .. are various opengl
> libs with fixed abi)

Thanks for the summarising the use case :)

Some potential issues with simply symlinking the libraries:

* The application would only retain a single dependency on the first symlink,
  unless it linked with -Wl,--no-as-needed.
* Not able to independently version the api libraries?

I think the important point for this use case is that we have a large
monolithic library (with global state), which applications expect to access via
multiple libraries. Symlinks were used in the past, and we're considering
both (1) and (2) as alternatives. The other potential solution is not having a
monolithic library.


Regards,

Dave.