This is the mail archive of the libc-alpha@sourceware.org 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]


> Florian Weimer
> 
> * David Kilroy:
> 
> >> 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
> 
> This symbolic link should not be there if there is no expectation that
> applications link directly with -limpl.
> 
> > 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
> 
> The two symbolic links above should probably go straight to
> libimpl.so.2.3.4 at run time, so that libimpl.so can be made optional.
> 
> > 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
> 
> Likewise here.
> 
> > 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.
> 
> The application must dlopen based on soname, which is either
> libapi_a.so.1 or libapi_b.so.3, and that will load libimpl.so.2.3.4.
> It
> must not use the link-time symbolic links, otherwise it risks picking
> up
> an incompatible library with a different ABI.  This is a general rule,
> it is not related to this setup.

Thanks for clarifying!

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

No particular reason - I'm just used to seeing the symlinks point to the
more specific versions of the library.


Thanks,

Dave.


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