Re: [Libguestfs] [PATCH nbdkit 2/2] vddk: Drive library loading from libdir parameter.

On 2/13/20 8:01 AM, Richard W.M. Jones wrote: >Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this >always causes problems because VDDK comes bundled with broken >replacements for system libraries, such as libcrypto.so and >libstdc++.so. Two problems this causes which we have seen in the real >world: > >(1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and >that breaks lots of ordinary utilities on their system. > >(2) nbdkit vddk --run subcommand inherits the LD_LIBRARY_PATH >environment variable from nbdkit, and common commands such as >'qemu-img' break, relying on complex workarounds like saving and >restoring the original LD_LIBRARY_PATH in the subcommand. > >Instead rely on a relatively undocumented feature of dlopen which is >that when we pass in a full path it will try to load dependent >libraries from the same directory. > >Note this may break some callers who are not using libdir and >expecting LD_LIBRARY_PATH to work, so it's a change in behaviour which >we will have to highlight prominently in the 1.18 release notes. > >Thanks: Dan Berrange, Ming Xie, Eric Blake. Do you want to use Dan's preferred UTF-8 spelling?

>+ if (asprintf (&path, "%s/lib%d/%s", >+ libdir ? : VDDK_LIBDIR, 8*SIZEOF_LONG, sonames[i]) == -1) { could you just spell this sizeof(long)*CHAR_BITS? I'm guessing that the vddk files always ship with a dir/lib32/xxx.so and a dir/lib64/xxx.so convention? Or, can we just hard-code the name '/lib64/', since...

But the idea looks sane to me. I don't have VDDK libraries installed so I can't readily test it, but assume this helps.