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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 18/12/2019 13:32, David Kilroy wrote:
>> Repost of v2 with updated commit message resulting from follow-up
>> tests with a different implementation.
>>
>> I'd still like to see this fixed, but the last patchset didn't get any
>> responses.
>>
>> v3:
>>  - rebased for changes in elf/Makefile
>>  - updates to commit messages
>>
>> v2:
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00701.html
>>  - code formatting fixups
>>  - add dependency of test output on filtee library
>>  - tests changed to use the test framework
>>
>> v1:
>> https://sourceware.org/ml/libc-alpha/2019-10/msg00519.html
> 
> Ping.  Is there any interest in taking this series, or something like it?
> I've seen that it needs another (almost trivial) rebase for changes in
> elf/Makefile, but don't want do that unnecessarily.

I think there is interest, the main problem is always lack of manpower
and time from reviewers to move this forward. I will try to spend some
time to review it.

> 
> It seems wrong that the toolchain can build a library as a forwarding library,
> but it only works if you link against it normally (and not via dlopen).
> 
> This BZ is also referenced from https://gitlab.freedesktop.org/glvnd/libglvnd#issues
> 
> We came across this as we were exploring different ways to support multiple
> stub libraries that at runtime forward to a single implementation library.
> The Solaris-like forwarding libraries are nice for this, as the forwarding is
> encapsulated in the compiled library.  What we end up doing is still under
> consideration - we have a few options including link scripts+symlinks as
> proposed by Florian in [1].  The different solutions have drawbacks for us,
> so having dlopen'able forwarding libraries would help by giving us another
> option.
> 

Thanks for the links, I see that this issue comes and go with different
solutions that hack into the loader (like that dlmopen namespace proposal
sometime ago). At least this seems to fix an already available solution 
and also adds some code refactor and cleanup.

> 
> Thanks,
> 
> Dave Kilroy.
> 
> [1] - https://sourceware.org/ml/libc-alpha/2019-10/msg00619.html
>