[Bug dynamic-link/15971] No interface for debugger access to libraries loaded with dlmopen

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15971

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Eric Blake from comment #3)
> I ran into this today while working on nbdkit; I needed a way to work around
> VDDK's buggy proprietary library that calls dlopen("libcrypto.so") on a
> relative path name but where the library comes with its own version of
> libcrypto.so that is incompatible with the one in /usr/lib, but I also need
> a solution that would not require LD_LIBRARY_PATH.

Why is LD_LIBRARY_PATH not an option?

If the inheritance by subprocesses is a problem, you could try an explicit
loader invocation with --library-path, or scrub the process environment after
the process has been loaded. (After program start, changing the environment
variable does not alter the search path.)

> My solution was to use
> dlmopen() to open a shim library defining an alternative dlopen(), so that I
> could intercept VDDK's poor dlopen calls and replace them with saner
> absolute loads.

It looks like you are reimplementing the la_objsearch hook from LD_AUDIT.

dlmopen seems the wrong solution for this because many things break with the
current implementation, not just debugging.

This is more of a topic for libc-help. Posting to random bug reports isn't
really the way to request help from your fellow Red Hatters.

-- 
You are receiving this mail because:
You are on the CC list for the bug.