On 24.09.2010 03:56, William A. Rowe Jr. wrote:
On 9/23/2010 6:58 PM, Jeff Trawick wrote:
These two are somewhat different in practice.
When the path to the binary is omitted on the invocation/load, the
shell/loader/whatever finds
* executables only because of the PATH envvar
Correct
* shared libraries usually via the system search path or in the
executable/other-library's
rpath
Typically, yes
PATH always, LD_LIBRARY_PATH in exceptional situations
And always permitted at the shell prior to execution. But once httpd has
started,
dropping LD_LIBRARY_PATH deprives the kernel of resolving such libraries, due to
our arbitrary choice to propagate PATH, but not propagate LD_LIBRARY_PATH...
leading
potentially to broken process invocations. Does this make sense?
E.g. the choice to propagate PATH, but not LD_LIBRARY_PATH, seems foolish. For
those
who wish to argue the 'unsafety' of relocatable/dynamic path resolutions, is
there
really any difference between propagating PATH but not LD_LIBRARY_PATH?
I guess I'm also missing the bigger picture, but:
- at first sight it sounds very reasonable to provide the
LD_LIBRARY_PATH as well
- it might result in problems, if the binary to start uses system libs,
which exist in LD_LIBRARY_PATH and in system default locations in
incompatible versions. IMHO this is more a theoretical problem. E.g. the
apr libs are versioned via the soname such that the runtime linker won't
link against a wrong version.
Regards,
Rainer
