This is the mail archive of the 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: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

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: and export a set of symbols.  this is abi
and there are multiple providers of and

one provider wants to have a single that
defines all the symbols of libA and libB as they share a
lot of code.

(1) having and as "wrapper libraries" around 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 and to makes
all symbols visible when either of them is loaded, polluting
the link namespace.

(4) creating two copies of 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

( is a video driver lib and libA, libB, .. are
various opengl libs with fixed abi)

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