search for: dt_runpath

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

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

...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 later with an examp...

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

...g 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? 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 duplicat...

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

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

On 2/17/20 9:12 AM, Florian Weimer wrote: > * Eric Blake: > >> I'm just now noticing that 'man ld' reports that you may pass '--audit >> LIB' during linking to add a DT_DEPAUDIT dependency on a library >> implementing the audit interface, which sounds like it might be an >> alternative to LD_AUDIT for getting a library with la_objsearch() to

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

Hi, OpenSSH 8.2p1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a feature release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via git using the instructions at