You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/04/15 16:47:34 UTC
proposed fix for funky Apache binbuild "issue"
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...
Re: proposed fix for funky Apache binbuild "issue"
Posted by Albert Chin <ne...@thewrittenword.com>.
On Mon, Apr 15, 2002 at 03:23:00PM -0400, Jeff Trawick wrote:
> Albert Chin <ne...@thewrittenword.com> writes:
>
> > > 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.
> >
> > According to ld.so.1(1) on Solaris 8/SPARC:
> > The runtime linker uses a prescribed search path for locat-
> > ing the dynamic dependencies of an object. The default
> > search paths are the runpath recorded in the object, fol-
> > lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
> > bit objects. This latter component can be modified using a
> > configuration file created with crle(1). The runpath is
> > specified when the dynamic object is constructed using the
> > -R option to ld(1). LD_LIBRARY_PATH can be used to indicate
> > directories to be searched before the default directories.
> >
> > Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
> > there any platform where this is not the case?
>
> On Linux the etched-in path is searched before LD_LIBRARY_PATH.
Ick.
> > > 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.
> >
> > The correct solution is re-linking on the target. Libtool does this by
> > default when installing the binary.
>
> Any idea what we have to change to make that happen? That requires
> shipping all the .o .lo .a .la, right?
Should be it. You'll then just run libtool --mode=link. The problem
though is the .la file contains parts of the build environment which
might not exist on the target. How would you deal with this? Take a
look at the .la file of an executable to see what I mean.
BTW, for executables, I think you only need .o whereas for libraries,
you need .o and .lo. Dunno if .a files are regenerated at install time
(might be as ranlib might need to be run on them for certain
platforms).
--
albert chin (china@thewrittenword.com)
Re: proposed fix for funky Apache binbuild "issue"
Posted by Albert Chin <ne...@thewrittenword.com>.
On Mon, Apr 15, 2002 at 03:23:00PM -0400, Jeff Trawick wrote:
> Albert Chin <ne...@thewrittenword.com> writes:
>
> > > 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.
> >
> > According to ld.so.1(1) on Solaris 8/SPARC:
> > The runtime linker uses a prescribed search path for locat-
> > ing the dynamic dependencies of an object. The default
> > search paths are the runpath recorded in the object, fol-
> > lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
> > bit objects. This latter component can be modified using a
> > configuration file created with crle(1). The runpath is
> > specified when the dynamic object is constructed using the
> > -R option to ld(1). LD_LIBRARY_PATH can be used to indicate
> > directories to be searched before the default directories.
> >
> > Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
> > there any platform where this is not the case?
>
> On Linux the etched-in path is searched before LD_LIBRARY_PATH.
Ick.
> > > 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.
> >
> > The correct solution is re-linking on the target. Libtool does this by
> > default when installing the binary.
>
> Any idea what we have to change to make that happen? That requires
> shipping all the .o .lo .a .la, right?
Should be it. You'll then just run libtool --mode=link. The problem
though is the .la file contains parts of the build environment which
might not exist on the target. How would you deal with this? Take a
look at the .la file of an executable to see what I mean.
BTW, for executables, I think you only need .o whereas for libraries,
you need .o and .lo. Dunno if .a files are regenerated at install time
(might be as ranlib might need to be run on them for certain
platforms).
--
albert chin (china@thewrittenword.com)
Re: proposed fix for funky Apache binbuild "issue"
Posted by Jeff Trawick <tr...@attglobal.net>.
Albert Chin <ne...@thewrittenword.com> writes:
> > 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.
>
> According to ld.so.1(1) on Solaris 8/SPARC:
> The runtime linker uses a prescribed search path for locat-
> ing the dynamic dependencies of an object. The default
> search paths are the runpath recorded in the object, fol-
> lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
> bit objects. This latter component can be modified using a
> configuration file created with crle(1). The runpath is
> specified when the dynamic object is constructed using the
> -R option to ld(1). LD_LIBRARY_PATH can be used to indicate
> directories to be searched before the default directories.
>
> Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
> there any platform where this is not the case?
On Linux the etched-in path is searched before LD_LIBRARY_PATH.
Here is an strace on Linux showing the etched-in path searched before
LD_LIBRARY_PATH:
execve("bin/httpd", ["bin/httpd"], [/* 36 vars */]) = 0
brk(0) = 0x8094b64
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx",
0xbffff4b4) = -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib", 0xbffff4b4) = -1
ENOENT (No such file or directory)
open("/tmp/2.0.35/lib/i686/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat("/tmp/2.0.35/lib/i686/mmx", 0xbffff4b4) = -1 ENOENT (No such file
or directory)
open("/tmp/2.0.35/lib/i686/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/i686", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/mmx", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/libaprutil.so.0", O_RDONLY) = 3
> > 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.
>
> The correct solution is re-linking on the target. Libtool does this by
> default when installing the binary.
Any idea what we have to change to make that happen? That requires
shipping all the .o .lo .a .la, right?
> BTW, are you talking about pre-compiled binaries provided by
> apache.org or pre-compiled binaries available in RPM/DEB/etc format?
binaries provided by apache.org
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: proposed fix for funky Apache binbuild "issue"
Posted by Jeff Trawick <tr...@attglobal.net>.
Albert Chin <ne...@thewrittenword.com> writes:
> > 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.
>
> According to ld.so.1(1) on Solaris 8/SPARC:
> The runtime linker uses a prescribed search path for locat-
> ing the dynamic dependencies of an object. The default
> search paths are the runpath recorded in the object, fol-
> lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
> bit objects. This latter component can be modified using a
> configuration file created with crle(1). The runpath is
> specified when the dynamic object is constructed using the
> -R option to ld(1). LD_LIBRARY_PATH can be used to indicate
> directories to be searched before the default directories.
>
> Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
> there any platform where this is not the case?
On Linux the etched-in path is searched before LD_LIBRARY_PATH.
Here is an strace on Linux showing the etched-in path searched before
LD_LIBRARY_PATH:
execve("bin/httpd", ["bin/httpd"], [/* 36 vars */]) = 0
brk(0) = 0x8094b64
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/mmx",
0xbffff4b4) = -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/i686", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib/mmx", 0xbffff4b4)
= -1 ENOENT (No such file or directory)
open("/home/trawick/apache/httpd-2.0.35/bindist/lib/libaprutil.so.0",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/trawick/apache/httpd-2.0.35/bindist/lib", 0xbffff4b4) = -1
ENOENT (No such file or directory)
open("/tmp/2.0.35/lib/i686/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat("/tmp/2.0.35/lib/i686/mmx", 0xbffff4b4) = -1 ENOENT (No such file
or directory)
open("/tmp/2.0.35/lib/i686/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/i686", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/mmx/libaprutil.so.0", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/tmp/2.0.35/lib/mmx", 0xbffff4b4) = -1 ENOENT (No such file or
directory)
open("/tmp/2.0.35/lib/libaprutil.so.0", O_RDONLY) = 3
> > 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.
>
> The correct solution is re-linking on the target. Libtool does this by
> default when installing the binary.
Any idea what we have to change to make that happen? That requires
shipping all the .o .lo .a .la, right?
> BTW, are you talking about pre-compiled binaries provided by
> apache.org or pre-compiled binaries available in RPM/DEB/etc format?
binaries provided by apache.org
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: proposed fix for funky Apache binbuild "issue"
Posted by Albert Chin <ne...@thewrittenword.com>.
On Mon, Apr 15, 2002 at 10:47:34AM -0400, Jeff Trawick wrote:
> 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.
According to ld.so.1(1) on Solaris 8/SPARC:
The runtime linker uses a prescribed search path for locat-
ing the dynamic dependencies of an object. The default
search paths are the runpath recorded in the object, fol-
lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
bit objects. This latter component can be modified using a
configuration file created with crle(1). The runpath is
specified when the dynamic object is constructed using the
-R option to ld(1). LD_LIBRARY_PATH can be used to indicate
directories to be searched before the default directories.
Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
there any platform where this is not the case?
> 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.
The correct solution is re-linking on the target. Libtool does this by
default when installing the binary.
BTW, are you talking about pre-compiled binaries provided by
apache.org or pre-compiled binaries available in RPM/DEB/etc format?
If the latter, I disagree with the solution of a NULL run-time search
path in the binary.
--
albert chin (china@thewrittenword.com)
Re: proposed fix for funky Apache binbuild "issue"
Posted by Albert Chin <ne...@thewrittenword.com>.
On Mon, Apr 15, 2002 at 10:47:34AM -0400, Jeff Trawick wrote:
> 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.
According to ld.so.1(1) on Solaris 8/SPARC:
The runtime linker uses a prescribed search path for locat-
ing the dynamic dependencies of an object. The default
search paths are the runpath recorded in the object, fol-
lowed by /usr/lib for 32-bit objects or /usr/lib/64 for 64-
bit objects. This latter component can be modified using a
configuration file created with crle(1). The runpath is
specified when the dynamic object is constructed using the
-R option to ld(1). LD_LIBRARY_PATH can be used to indicate
directories to be searched before the default directories.
Therefore, LD_LIBRARY_PATH is searched *before* the etched-in path. Is
there any platform where this is not the case?
> 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.
The correct solution is re-linking on the target. Libtool does this by
default when installing the binary.
BTW, are you talking about pre-compiled binaries provided by
apache.org or pre-compiled binaries available in RPM/DEB/etc format?
If the latter, I disagree with the solution of a NULL run-time search
path in the binary.
--
albert chin (china@thewrittenword.com)