Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 10 Dec 2001 21:45:58 -0800
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: Jeff Trawick <trawick@attglobal.net>
Cc: dev@apr.apache.org
Subject: Re: cvs commit: apr Makefile.in
Message-ID: <20011211054558.GG23203@ebuilt.com>
References: <20011211014210.60105.qmail@icarus.apache.org>
 <m3667e4gxd.fsf@rdu163-40-092.nc.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3667e4gxd.fsf@rdu163-40-092.nc.rr.com>
User-Agent: Mutt/1.3.23.2i

On Mon, Dec 10, 2001 at 09:41:18PM -0500, Jeff Trawick wrote:
> Shortly after these commits I get the following on a system with libtool
> 1.3.4.  Coincidence?

Probably not.  Well, let me explain why I think this commit is 
necessary.  The problem is that APR and APR-util aren't playing 
very nice when you try to build packages that may not have APR in 
the source tree.  I'll call packages that contain APR in the source
tree to contain bundled versions (i.e. httpd).  And, packages that 
rely on installed copies are unbundled (i.e. SVN or flood).

Take a look at apr-util's export_vars.sh:

APRUTIL_EXPORT_LIBS="-lgdbm -ldb /home/jerenkrantz/cvs-apache/httpd-2.0/srclib/apr-util/xml/expat/lib/libexpat.la"

This file is *completely* bogus.  We are indicating that they require 
the source directory to build apr-util correctly (partly because I'm 
using the bundled expat and httpd/flood/SVN need to link against the
right external libraries).  Indicating the source dir is evil.  But,
we can't also specify the prefix either because of bundling - if
it was $prefix/lib/libexpat.la, httpd-2.0 would die since apr-util
hasn't been installed yet, so libexpat.la doesn't exist.  We're in 
a Catch-22 here (not to mention that export_vars.sh isn't even 
installed by apr-util!).

And, this is where libtool and this commit come in.  libtool has 
this functionality built-in.  If we specify the libraries we depend
on when we build the .la file, libtool will record them and ensure 
that any libtool-aware build (i.e. httpd) will link in the right 
libraries without any knowledge by httpd of these dependencies.  The
nice thing is that when we install the .la file via libtool, it'll 
change the paths to things like a bundled expat.  The uninstalled 
libaprutil.la will cite $builddir/xml/expat/lib/libexpat.la and the 
installed libaprutil.la will call $prefix/lib/libexpat.la.  That's 
exactly what we want to have happen.

So, we can remove the need for export_vars.sh and potentially 
clean up APRVARS to have less stuff in it (and possibly move to 
an apr-config shell script to replace APRVARS).  All that a 
third-party has to do is link in libapr(util).la and everything 
works.  IMHO, this is general goodness and we should do this.

Now, that you hopefully understand where I'm coming from, let me 
postulate what may be going on:

1) Is it possible you have --disable-shared turned on?  I'm not
   sure if this would affect libtool, but it might turn off 
   dependency checks.  All we want to do is populate the 
   dependency_libs variable in libapr(util).la.  Passing the 
   library names at link-time seems to be the way to do it.
   In addition, these variables could also be passed on to the 
   linker which could in theory barf on them when building a
   static library.  I just don't know.  (What OS is this?)
2) It is possible that the dependency generation of older
   libtools is broken.  I'd suggest that the benefit of
   upgrading to this scheme (i.e. removing export_vars.sh
   and relying on libtool to handle it) is worth forcing
   developers to upgrade to whatever version has correct
   dependency handling (my guess would be libtool 1.4+).

Sadly, my bet is on #2.

I hope my rationale is clear.  =)  If not, I'll just keep 
trying to make myself understood.  -- justin