apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof ...@apache.org>
Subject [PATCH] apr-util symlink problem in configure for expat
Date Thu, 12 Dec 2002 09:42:00 GMT
We're using Apache 2.0.43, with apr-util built from within the Apache
tree.  We recently (around the time we upgraded to 2.0.43) found a
problem where apr-util stopped building the expat it contains (which is
the expat we want to use) if the build was started from a symlinked
directory.  The problem is that in configure, the attempt to determine
if the expat_include_dir is inside apr-util contains one canonicalized
path, and one path accessed via a symlink.

The relevant if/else block looks like this in my srclib/apr-util
directory:

if test "$expat_include_dir" = "xml/expat/lib" -o "$expat_include_dir" =
"xml/expat-cvs/lib"; then

...

else
if test "$expat_include_dir" = "$srcdir/xml/expat/include" -o
"$expat_include_dir" = "$srcdir/xml/expat/lib"; then

...

The second one is the one should test true in the context that we are
using this.  It was working for some people and not others; bread crumbs
turned up the fact that the two dirs were the same, but wouldn't test
the same with a string compare because expat_include_dir started with a
path to a symlink.  Using the canonicalized version of srcdir (available
as abs_srcdir, at least in configure) fixed the problem.

We start by invoking httpd's general configure script with something
like the following (/home/ed/src is a symlink to /opt/src and
/home/ed/target is a symlink to /opt/target in this example -- the paths
have been simplified), run from within

	/home/ed/src/tmp/httpd-2.0.43

taken from config.status in that directory:

# ./configure  --with-mpm=prefork
	--bindir=/home/ed/target/bin
	--sbindir=/home/ed/target/bin
	--includedir=/home/ed/target/include
	--libdir=/home/ed/target/lib/apache
	--libexecdir=/home/ed/target/lib/apache
	--mandir=/home/ed/target/docs/man
	--datadir=/home/ed/target/bin
	--sysconfdir=/home/ed/target/conf/apache-20
	--localstatedir=/home/ed/target/bin/var
	--enable-modules=all
	--enable-ssl
	--disable-auth-digest
	--enable-dav
	--enable-rewrite
	--enable-proxy
	--enable-so
	--enable-static-support
	--with-berkeley-db=/home/ed/target/bin/BerkeleyDB-40/include:/home/ed/target/lib/BerkeleyDB-40
	--with-expat=/home/ed/src/tmp/httpd-2.0.43/srclib/apr-util/xml/expat
	--prefix=/home/ed/target/bin


Note that all the options start with the symlink, rather than the
canonical path.  Also note the inclusion of --with-expat ...  This then
generates a configure call within srclib/apr-util which looks like this
(taken from config.status in apr-util):

# /opt/src/tmp/httpd-2.0.43/srclib/apr-util/configure
	--with-mpm=prefork
	--bindir=/home/ed/target/bin
	--sbindir=/home/ed/target/bin
	--includedir=/home/ed/target/include
	--libdir=/home/ed/target/lib/apache
	--libexecdir=/home/ed/target/lib/apache
	--mandir=/home/ed/target/docs/man
	--datadir=/home/ed/target/bin
	--sysconfdir=/home/ed/target/conf/apache-20
	--localstatedir=/home/ed/target/bin/var
	--enable-modules=all --enable-ssl --disable-auth-digest --enable-dav
	--enable-rewrite --enable-proxy --enable-so --enable-static-support
	--with-berkeley-db=/home/ed/target/bin/BerkeleyDB-40/include:/home/ed/target/lib/BerkeleyDB-40
	--with-expat=/home/ed/src/tmp/httpd-2.0.43/srclib/apr-util/xml/expat
	--prefix=/home/ed/target/bin
	--cache-file=/opt/src/tmp/httpd-2.0.43/./config.cache
	--srcdir=/opt/src/tmp/httpd-2.0.43/srclib/apr-util
	--with-apr=../apr
	--prefix=/home/ed/target/bin
	--exec-prefix=/home/ed/target/bin
	--libdir=/home/ed/target/lib/apache
	--includedir=/home/ed/target/include
	--bindir=/home/ed/target/bin

Apparently, for some reason Apache managed to canonicalize some of the
tokens, but not all of them.  This is on a linux RH 7.3 box, so pwd does
not canonicalize a symlinked path when /bin/sh is the shell; /bin/pwd is
required for that.

The attached patch resolves the issue I was seeing, through insisting on
proper canonicalization when testing paths known only as strings.

This may be new since Apache 2.0.42 (we just switched to 2.0.43); it's
also arguable that a better solution is making the canonicalization
correct and consistent in Apache's configure script.  I'm not sure that
using /bin/pwd is portable; and another solution was to run Apache's
configure with --srcdir pointing to the full path as our build system
knows it (using the symlink).  But after doing this debugging, I figured
better path canonicalization might be of general interest.

thanks --

Ed

Mime
View raw message