httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c
Date Fri, 24 Sep 2010 16:12:56 GMT
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

Mime
View raw message