Hi Chris, Am 08.04.2016 um 18:09 schrieb Rainer Canavan:
On Fri, Apr 8, 2016 at 6:02 PM, Christopher Schultz <chris@xxxxxxxxxxxxxxxxxxxxxx> wrote: [...]I'm speaking from a position of ignorance, here, but can a dynamic library modify the main process's search path? If only mod_ssl is compiled with the static-path to OpenSSL but httpd is not (and it's not clear to me that httpd is missing this static-path), surely the loadable module isn't modifying the process's library load-path, is it?The manpage would indicate that the rnupath is only valid for the library for which it has been set: https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7md6/index.html The runtime linker uses a prescribed search path for locating the dynamic dependencies of an object. The default search paths are therunpath recorded in the object, followed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-bit objects. This latter component can be modified using a configuration file created with crle(1). The runpath is specified when the dynamic object is constructed using the -Roption to ld(1). LD_LIBRARY_PATH can be used to indicate directories to be searched before the default directories.
Adding to that for Solaris: - there's the loading of the dependencies and - there's symbol resolution in the loaded objectsThe loading of the dependencies happens immediately. The name of the dependencies are encoded in the shared object as the NEEDED entries.
Example:
index tag value
[0] NEEDED 0x1331 libssl.so.1.0.0
[1] NEEDED 0x1341 libcrypto.so.1.0.0
These are shared object names, not file names.
Looking at some file libssl.so we can see its shared object name:
index tag value
...
[7] SONAME 0x4930 libssl.so.1.0.0
Aha, so that file would satisfy the dependency. The SONAMEs are
typically chosen to express API compatibility.
Where are the files searched for? That's the question Rainer Canavan just answered. First on the RUNPATH set in the shared object for which we are looking for the dependencies, then in the LD_LIBRARY_PATH, then in the globally defined search path.
Example RUNPATH entry:
index tag value
...
[6] RUNPATH 0x101ff /some/path/lib
[7] RPATH 0x101ff /some/path/lib
The ldd command (and ldd -v) shows us the list of dependencies and where
they are found, but "elfdump -d" resp. "objdump -p" helps to understand,
what the modules/libs originally demanded.
Finally there comes symbol resolution, i.e. a function that is called in a shared object, but provided by another loaded shared object like the OpenSSL library. Such a symbol is searched for in the binary and the full tree of loaded shared objects and dependencies of this process. On Solaris the default order - which can be changed during build time - is always first searching in the main binary and then in the other shared objects in the order they were loaded. So e.g. a symbol needed by mod_ssl will first be looked up in httpd, then in the libs loaded by httpd directly, then in the various web server modules and their dependencies until finally found e.g. in libssl. One can build modules so that symbols are always first searched in their direct dependencies before searching in the rest of the process, but that's not the default.
Regards, Rainer (the other one) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|