search for: vddk_default_libdir

We were previously dlopen-ing it in the load() method. This is very early and in particular means that the only possible way to configure where we find the library is through environment variables and not through config parameters. Also it's not necessary as we don't call any functions from the library (such as VixDiskLib_InitEx) until config_complete. This change is neutral refactoring

...y the VDDK distribution directory should be passed as the -C<libdir> parameter and set C<LD_LIBRARY_PATH> to the F<lib64> -subdirectory: +You can two choices: Place VDDK in the default libdir which is +compiled into this plugin, for example: + + $ nbdkit vddk --dump-plugin | grep ^vddk_default_libdir + vddk_default_libdir=/usr/lib64/vmware-vix-disklib + +But the most common way is to set the C<libdir> parameter to point to +F<vmware-vix-disklib-distrib/> (which you can unpack anywhere you +like), and this plugin will find the VDDK library from there. For +example: - LD_LIBRARY_PA...

...rectory should be passed as the -C<libdir> parameter and set C<LD_LIBRARY_PATH> to the F<lib64> -subdirectory: +You have two choices: + +=over 4 + +=item * + +Place VDDK in the default libdir which is compiled into this plugin, +for example: + + $ nbdkit vddk --dump-plugin | grep ^vddk_default_libdir + vddk_default_libdir=/usr/lib64/vmware-vix-disklib + +=item * + +But the most common way is to set the C<libdir> parameter to point to +F<vmware-vix-disklib-distrib/> (which you can unpack anywhere you +like), and this plugin will find the VDDK library from there. For +example: - LD_...

...passed as the > -C<libdir> parameter and set C<LD_LIBRARY_PATH> to the F<lib64> > -subdirectory: > +You can two choices: Place VDDK in the default libdir which is s/can/have/ > +compiled into this plugin, for example: > + > + $ nbdkit vddk --dump-plugin | grep ^vddk_default_libdir > + vddk_default_libdir=/usr/lib64/vmware-vix-disklib > + > +But the most common way is to set the C<libdir> parameter to point to > +F<vmware-vix-disklib-distrib/> (which you can unpack anywhere you > +like), and this plugin will find the VDDK library from there. For &g...

...ig_key = "file", .dump_plugin = vddk_dump_plugin, .open = vddk_open, .close = vddk_close, diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh index d99ebf88..6933f716 100755 --- a/tests/test-vddk.sh +++ b/tests/test-vddk.sh @@ -48,8 +48,7 @@ grep ^vddk_default_libdir= test-vddk.out # a load that we know will fail, but the important part is that dlopen's # error message lists an absolute file even though we passed a relative # name, showing that our shim did adjust it. -nbdkit vddk libdir=.libs \ - file=/dev/null --run ':' 2> test-vddk.err ||...

...rectory should be passed as the -C<libdir> parameter and set C<LD_LIBRARY_PATH> to the F<lib64> -subdirectory: +You have two choices: + +=over 4 + +=item * + +Place VDDK in the default libdir which is compiled into this plugin, +for example: + + $ nbdkit vddk --dump-plugin | grep ^vddk_default_libdir + vddk_default_libdir=/usr/lib64/vmware-vix-disklib + +=item * + +But the most common way is to set the C<libdir> parameter to point to +F<vmware-vix-disklib-distrib/> (which you can unpack anywhere you +like), and this plugin will find the VDDK library from there. For +example: - LD_...

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

...p_plugin = vddk_dump_plugin, > .open = vddk_open, > .close = vddk_close, > diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh > index d99ebf88..6933f716 100755 > --- a/tests/test-vddk.sh > +++ b/tests/test-vddk.sh > @@ -48,8 +48,7 @@ grep ^vddk_default_libdir= test-vddk.out > # a load that we know will fail, but the important part is that dlopen's > # error message lists an absolute file even though we passed a relative > # name, showing that our shim did adjust it. > -nbdkit vddk libdir=.libs \ > - file=/dev/null --run ':'...

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

...rectory should be passed as the -C<libdir> parameter and set C<LD_LIBRARY_PATH> to the F<lib64> -subdirectory: +You have two choices: + +=over 4 + +=item * + +Place VDDK in the default libdir which is compiled into this plugin, +for example: + + $ nbdkit vddk --dump-plugin | grep ^vddk_default_libdir + vddk_default_libdir=/usr/lib64/vmware-vix-disklib + +=item * + +But the most common way is to set the C<libdir> parameter to point to +F<vmware-vix-disklib-distrib/> (which you can unpack anywhere you +like), and this plugin will find the VDDK library from there. For +example: - LD_...

...> > .open = vddk_open, > > .close = vddk_close, > > diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh > > index d99ebf88..6933f716 100755 > > --- a/tests/test-vddk.sh > > +++ b/tests/test-vddk.sh > > @@ -48,8 +48,7 @@ grep ^vddk_default_libdir= test-vddk.out > > # a load that we know will fail, but the important part is that dlopen's > > # error message lists an absolute file even though we passed a relative > > # name, showing that our shim did adjust it. > > -nbdkit vddk libdir=.libs \ > > - file=/...

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