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

[Szabolcs Nagy <Szabolcs.Nagy@arm.com>]

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.

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