search for: libvixdisklib

...directories: the usual VDDK installation puts .so > + * files in an arch-specific subdirectory of $libdir (although > + * only VDDK 5 supported 32-bit); but in our testsuite is easier > + * to write if we point libdir directly to a stub .so. > + */ > + "lib64/libvixDiskLib.so.6", > "libvixDiskLib.so.6", > + "lib64/libvixDiskLib.so.5", > + "lib32/libvixDiskLib.so.5", > "libvixDiskLib.so.5", Should we put #ifdef around the lib64/ and lib32/ versions? Another alternative might be to get rid of th...

...point libdir directly to a stub .so. + * files in an arch-specific subdirectory of $libdir (our minimum + * supported version is VDDK 5.5.5, which only supports x64-64); + * but our testsuite is easier to write if we point libdir + * directly to a stub .so. */ "lib64/libvixDiskLib.so.6", "libvixDiskLib.so.6", "lib64/libvixDiskLib.so.5", - "lib32/libvixDiskLib.so.5", "libvixDiskLib.so.5", }; size_t i; -- 2.26.0.rc2

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

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

...ot;x$is_windows" = "xyes"]) - AC_SEARCH_LIBS([getaddrinfo], [network socket]) dnl Check for SELinux socket labelling (optional). diff --git a/tests/Makefile.am b/tests/Makefile.am index 562558d0..f9c6b8ad 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -833,13 +833,9 @@ libvixDiskLib_la_CXXFLAGS = $(WARNINGS_CFLAGS) # For use of the -rpath option, see: # https://lists.gnu.org/archive/html/libtool/2007-07/msg00067.html libvixDiskLib_la_LDFLAGS = \ - -shared -version-number 6:0:0 -rpath /nowhere \ + -shared -version-number 6:0:0 -no-undefined -rpath /nowhere \ $(NULL) -if...

...9;s a change in behaviour which we will have to highlight prominently in the 1.18 release notes. We can also use our dlopen() probing to simplify our testsuite - even though the real VDDK requires LD_LIBRARY_PATH to point to vmware-vix-disklib-distrib/lib64, the fact that we probe both "lib64/libvixDiskLib.so.6" and "libvixDiskLib.so.6" means that our testsuite's dummy library can live at tests/.libs/libvixDiskLib.so.6, while still covering functionality. Thanks: Dan Berrangé, Ming Xie, Eric Blake. [eblake: Several modifications to Rich's initial patch, mainly to take advantag...

...point libdir directly to a stub .so. + * files in an arch-specific subdirectory of $libdir (our minimum + * supported version is VDDK 5.5.5, which only supports 64-bit); + * but our testsuite is easier to write if we point libdir + * directly to a stub .so. */ "lib64/libvixDiskLib.so.6", "libvixDiskLib.so.6", "lib64/libvixDiskLib.so.5", - "lib32/libvixDiskLib.so.5", "libvixDiskLib.so.5", }; size_t i; -- 2.24.1

In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard

...pen library: libcrypto.so.1.0.2: cannot open shared object file: No such file or directory. I was curious if the replacement dlopen() was being called at all, and it is certainly called from plugins/vddk/vddk.c: nbdkit: debug: dlopen: /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.6 flags=2 It's also called from VDDK itself: nbdkit: debug: dlopen: /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so flags=257 but it's not being explicitly called for libcrypto.so because immediately after the above message I see the error: nbdkit...

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

...plugins/vddk/nbdkit-vddk-plugin.pod index a7300e94..11d12c3f 100644 --- a/plugins/vddk/nbdkit-vddk-plugin.pod +++ b/plugins/vddk/nbdkit-vddk-plugin.pod @@ -233,26 +233,47 @@ This parameter is ignored for backwards compatibility. =head1 LIBRARY AND CONFIG FILE LOCATIONS -If the VDDK library (F<libvixDiskLib.so.I<N>>) is located on a -non-standard path, you may need to set C<LD_LIBRARY_PATH> or modify -F</etc/ld.so.conf> before this plugin will work. In addition you may -want to set the C<libdir> parameter so that the VDDK library can load -plugins like Advanced Transport. +...

...vddk/vddk.c @@ -143,54 +143,7 @@ error_function (const char *fs, va_list args) nbdkit_error ("%s", str); } -/* Load and unload the plugin. */ -static void -vddk_load (void) -{ - static const char *sonames[] = { - /* Prefer the newest library in case multiple exist. */ - "libvixDiskLib.so.6", - "libvixDiskLib.so.5", - }; - size_t i; - CLEANUP_FREE char *orig_error = NULL; - - /* Load the library. */ - for (i = 0; i < sizeof sonames / sizeof sonames[0]; ++i) { - dl = dlopen (sonames[i], RTLD_NOW); - if (dl != NULL) - break; - if (i == 0) { -...

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

...1.0.2: cannot open shared object file: No such file or directory. > > I was curious if the replacement dlopen() was being called at all, and > it is certainly called from plugins/vddk/vddk.c: > > nbdkit: debug: dlopen: /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.6 flags=2 > > It's also called from VDDK itself: > > nbdkit: debug: dlopen: /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so flags=257 That's nice to know... > > but it's not being explicitly called for libcrypto.so because &g...

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

...ds. fork kills these, resulting in the s/kills/strands/ > library hanging or failing completely in certain configurations. > --- > plugins/vddk/vddk.c | 28 ++++++++++++++++++++++------ > 1 file changed, 22 insertions(+), 6 deletions(-) > ACK. Should we also modify our tests/libvixDiskLib.so dummy library to also spawn a thread, where .pread then checks for something provided by that helper thread, for testsuite coverage of this? That's a rather complicated change to make, so I'm not insisting, but if you're up to it, the more our dummy library behaves like the real...

I'm a lot happier with this version: no mucking with dlmopen(). It does add a bit more coupling between nbdkit proper and the vddk plugin (namely, nbdkit now exports a new function that the vddk plugin relies on), but patch 2 adds testsuite coverage of the new function so we shouldn't regress. Patch 1 and 2 are new, patch 3 is unchanged from when Rich posted it in v2, and patch 4 is

...STUB (VixDiskLib_GetErrorText, char *, (VixError err, const char *unused)); diff --git a/tests/dummy-vddk.c b/tests/dummy-vddk.c index ed5d3712..13be492d 100644 --- a/tests/dummy-vddk.c +++ b/tests/dummy-vddk.c @@ -30,18 +30,24 @@ * SUCH DAMAGE. */ -/* This file pretends to be libvixDiskLib.so.6. - * - * However it only implements --dump-plugin support so our stubs don't - * need to do anything. - */ +/* This file pretends to be libvixDiskLib.so.6. */ #include <stdio.h> #include <stdlib.h> #include <stdint.h> +#include <string.h> #include "vddk...

...dir=/path/to/vddklibs file --run 'program args' Sequentially, we have this scenario: nbdkit vddk libdir=/path/to/libs file --run 'program args' - nbdkit binary calls dlopen("/path/to/nbdkit-vddk-plugin.so") - nbdkit-vddk-plugin.so calls dlopen("/path/to/libs/libvixDiskLibs.so") using the libdir= argument to load vddk (rather than dlopen("libvixDiskLibs.so") relying on LD_LIBRARY_PATH) - vddk's initializer calls dlopen("libcrypto.so") expecting to open /path/to/libs/libcrypto.so, but either LD_LIBRARY_PATH made that...