Using LD_RUN_PATH
Douglas C. Schmidt
I'm trying to understand how the LD_RUN_PATH environment
variable is suppose to work on SunOS 5.3. From the documentation, it
sounds like the run-time linker searches the directories specified in
this env. variable to determine where to locate a shared object file.
However, when I experiment, it seems that the SunOS 5.3 run-time
linker ignores the contents of this variable (as does ldd).
Conversely, the LD_LIBRARY_PATH environment variable *is* searched at
run-time and does seem to work fine.
Am I missing something fundamental about the difference
between LD_RUN_PATH and LD_LIBRARY_PATH?
Thanks,
Doug
--
Dr. Douglas C. Schmidt
Department of Computer Science
Washington University
St. Louis, MO 63130. Work #: (314) 935-7538; FAX #: (314) 035-7302
Jonathan Doughty
Douglas> I'm trying to understand how the LD_RUN_PATH environment
Douglas> variable is suppose to work on SunOS 5.3. From the documentation, it
Douglas> sounds like the run-time linker searches the directories specified in
Douglas> this env. variable to determine where to locate a shared object file.
Douglas> However, when I experiment, it seems that the SunOS 5.3 run-time
Douglas> linker ignores the contents of this variable (as does ldd).
Douglas> Conversely, the LD_LIBRARY_PATH environment variable *is* searched at
Douglas> run-time and does seem to work fine.
Douglas> Am I missing something fundamental about the difference
Douglas> between LD_RUN_PATH and LD_LIBRARY_PATH?
Read the man page again, in particular the entry for -R. LD_RUN_PATH
is an alternative to using -R:
-R path A colon-separated list of directories used to
specify library search directories to the run-
time linker. If present and not null, it is
recorded in the output object file and passed to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the run-time linker. Multiple instances of this
option are concatenated together with each path
separated by a colon.
In short, developers set LD_RUN_PATH when building executables so that
users needn't bother with mucking about with LD_LIBRARY_PATH. Note,
though, that a user LD_LIBRARY_PATH setting will over-ride an
LD_RUN_PATH setting recorded in the executable. So it's still
possible for confusion to reign.
-----------------------------------------------------------------------
Jonathan Doughty The MITRE Corporation jo...@mitre.org
Rod Evans
> I'm trying to understand how the LD_RUN_PATH environment
> variable is suppose to work on SunOS 5.3. From the documentation, it
> sounds like the run-time linker searches the directories specified in
> this env. variable to determine where to locate a shared object file.
> However, when I experiment, it seems that the SunOS 5.3 run-time
> linker ignores the contents of this variable (as does ldd).
> Conversely, the LD_LIBRARY_PATH environment variable *is* searched at
> run-time and does seem to work fine.
LD_RUN_PATH is *only* interpreted by ld(1). ld(1) takes the path specified
by this environment variable and stuffs it in the image being created. This
recording can be displayed using dump(1):
% dump -pLv /usr/openwin/bin/shelltool
/usr/openwin/bin/shelltool:
[INDEX] Tag Value
[1] NEEDED libxview.so.3
.......
[12] RPATH /usr/openwin/lib
This `RPATH' (runpath) will be used by the runtime linker (and ldd) to search
for any dependencies.
LD_RUN_PATH is a confusing mechanism of passing information to ld(1). The use
of ld(1)'s -R option provides an alternative, more flexible, and more
intuitive mechanim of providing the same information.
LD_LIBRARY_PATH is used by both ld(1) and the runtime linker.
Rod.
Stainless Steel Rat
Douglas> I'm trying to understand how the LD_RUN_PATH environment
Douglas> variable is suppose to work on SunOS 5.3.
It works almost identically to the -R ld switch. The contents of
LD_RUN_PATH are inserted into the file created by the linker. When the
binary searches for shared libraries, it searches that path for them.
Douglas> Conversely, the LD_LIBRARY_PATH environment variable *is* searched
Douglas> at run-time and does seem to work fine.
LD_LIBRARY_PATH should be unset; it will override LD_RUN_PATH/ld -R
settings. The logic works something like this: if LD_LIBRARY_PATH is set,
search for shared libraries there; if it isn't set and if a search path is
compiled into the binary (LD_RUN_PATH/ld -R <path>) then search there. If
the library can't be found, then search in /usr/lib or /usr/ccs/lib.
Finally, if the library still can't be found, ld returns an error.
You should never need to use LD_LIBRARY_PATH; if you do, then something has
been set up incorrectly.
--
Rat <rat...@ccs.neu.edu> |"The only way to deal with temptation is to
http://www.ccs.neu.edu/home/ratinox|yield to it." --Oscar Wilde
PGP Public Key: Ask for one today! |