Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?

On Fri, Feb 21, 2020 at 04:00:30PM +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote: > >> I think what confuses me is that keep talking about a single binary, but > >> clearly there is this separate vddk DSO, and there is talk of plugins. > >> So it seems to me that multiple files are involved already? > > > > nbdkit is a standalone binary that happens to be able to load plugins > > from a well-known path, eg nbdkit-vddk-plugin.so. nbdkit knows the > > path for plugins, and there's a wrapper allowing it to get local > > plugins even when it's still in the build directory. Adding another > > file would mean another path (or overloading the meaning of the plugin > > path) and just makes the whole thing more fragile and complex. > > > > Having said all that, what would also solve this is either an API for > > updating LD_LIBRARY_PATH after the program has started; or making > > setenv ("LD_LIBRARY_PATH",...) DTRT*; or some kind of dlopen() variant > > which takes a library path as an extra parameter. > > Have you tried adding DT_RUNPATH or DT_RPATH to nbdkit-vddk-plugin.so? > Or does the path have to be chosen dynamically? To be clear, the situation is: nbdkit (free) -> dlopens nbdkit-vddk-plugin.so (free) -> dlopens libvixDiskLib.so (proprietary) -> dlopens other proprietary plugins -> both libvixDiskLib.so and its plugins have DT_NEEDED "libstdc++.so.X" and other objects that have odd/old compiled versions in its own directory It's the proprietary library libvixDiskLib.so (colloquially known as "VDDK") which has trouble opening its own plugins. I guess you mean adding DT_* to the proprietary library?