On Fri, Feb 21, 2020 at 05:02:12PM +0100, Florian Weimer wrote:
* Richard W. M. Jones:
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?
No, to nbdkit-vddk-plugin.so.
But it looks like have misunderstood the request.
Do you want to inhibit loading the libstdc++.so.X from vddk, or the opposite—ensure that it is loaded? The latter obviously taints the process. But maybe that's what you want?
Ideally load it but only make it available to VDDK. I think Eric was working on something along these lines, using dlmopen. We're sort of lucky that none of the libraries that VDDK tries to load overlaps with libraries that nbdkit uses (currently). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW