apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject proposed fix for funky Apache binbuild "issue"
Date Mon, 15 Apr 2002 14:47:34 GMT
For Apache binary distributions, an environment variable (e.g.,
LD_LIBRARY_PATH) is used at run-time to locate libapr, libaprutil,
libexpat, etc. because the path etched into the httpd executable is
the path used when creating the binary distribution, not the path used
for the actual install.

But there is a problem with this: LD_LIBRARY_PATH is always searched
after the etched-in path.  Also, the etched-in path is searched before
the system path.

If you create binary distributions and you install/run binary
distributions on the same machine you can end up getting the wrong
copy of libraries.

Everybody starting httpd has extra load overhead as the etched-in path
(which is never appropriate) is searched for all libraries (including
libc).

I think we'd be better off if there were no path etched into httpd for
a binary distribution.  (This could be useful for more than just the
binbuild.sh scenario.)  Unfortunately, it isn't clear how to do this
with libtool.  When apr.la is created -rpath is required.  It then
goes into apr.la and I think that is what results in the etched-in
path for httpd.

Any ideas on how to deal with this issue?

It would be nicer to just replace the etched-in value at install
time.  I don't think that libtool can do that unless you do a re-link
on the target machine.  We could binary-edit the path within the
executable but that doesn't sound very maintainable.

Statically linking libraries into httpd for a binary build would
presumably avoid the whole issue.  What problems would that present?

Thanks,

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message