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

[David Kilroy]

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

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,

Dave Kilroy.

[1] - https://sourceware.org/ml/libc-alpha/2019-10/msg00619.html