httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c
Date Fri, 24 Sep 2010 17:09:10 GMT
On Fri, Sep 24, 2010 at 12:50 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net>wrote:

> On 9/24/2010 11:12 AM, Rainer Jung wrote:
> >
> > 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.
>
> But these same problems would be true at the shell, prior to invoking
> httpd, no?
>

httpd could pick up library paths from the shell, but it could also pick up
paths from bin/envvars; the latter is specifically tailored for dependencies
bundled+built with httpd (and same ABI/debug-ability/etc.); for the slim
cases where those defs are not irrelevant for the normal CGI/FastCGI, I
dunno whether it would be good or bad more often

This could be discussed purely in terms of features we already have:

Do admins find 'SetEnv LD_LIBRARY_PATH foo' or 'PassEnv LD_LIBRARY_PATH' to
solve their problem most often?
How often is it problematic to use 'PassEnv LD_LIBRARY_PATH'?

Mime
View raw message