Hi Chris,
Am 08.04.2016 um 18:09 schrieb Rainer Canavan:
On Fri, Apr 8, 2016 at 6:02 PM, Christopher Schultz
<ch...@christopherschultz.net> 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 objects
The 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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
