search for: dt_rpath

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

...tag and value pairs. These entries are interpreted (and potentially validated) before being written to the .dynamic section. The simplest way to satisfy this requirement is for all dynamic entry values to be numeric values. Unfortunately, this inherently prevents entries like DT_SONAME, DT_NEEDED, DT_RPATH, and DT_RUNPATH from being specified alongside dynamic symbols due to the design of yaml2obj. This proposal introduces three ways to input a value for a dynamic entry. For a given dynamic tag, one or more of these methods of setting a value may be permitted. All of these cases are illustrated lat...

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

R developers, I am trying to understand how symbols are resolved, so that I can configure a package that I contributed to, and so that I can provide guidance to (linux / OSX) users of the package. To be concrete, my package uses the LAPACK Fortran symbol zsysv. This is not in libRlapack, but is defined on my system in the library /usr/lib64/liblapack.so. * I suspect that the reason the symbol is

...t, 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? If you merely want to prevent loading of libstdc++.so or libcrypto.so by vddk, it may be possible to explicitly dlopen DSOs of that name before loading vddk. But there is an existing bug where we do not duplicate properly o...

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

...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) > &gt...

I've got a situation where I need to hook a dlopen() made by VDDK, a proprietary library, where it passes a relative name expecting to resolve to a copy of several libraries, including libstdc++.so, that it installs alongside itself, and fails to load if that resolves to the system libstdc++.so. The simplest solution of providing LD_LIBRARY_PATH is enough to load VDDK, but then poisons