apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject use of libtool (was: Re: cvs commit: apr-util/test .cvsignore Makefile.in)
Date Sat, 02 Dec 2000 21:54:53 GMT
On Sat, Dec 02, 2000 at 09:18:12AM -0800, rbb@covalent.net wrote:
> > Note that it uses autoconf and libtool. It isn't complicated enough for
> > automake, so I didn't bother. The build stuff is also greatly simplified
> > over those in APR and Apache. A single build/rules.mk and teeny makefiles
> > throughout.
> I would really prefer to not use libtool.  This is meant to be a library
> that is useful to external projects.  Apache has had some real problems
> using libtool, and it is impossible for non-libtool projects to use a
> libtool library.

Well, unlike Apache, we need to be able to create a shared library for
consumption by other programs. (Apache only needs dynamic-load modules) To
build a shared library, libtool is the best available option.

At install time, libtool will spit out the right files: there will be a .a
file, a versioned .so file (e.g. libaprutil.so.x.y.z), and the symlinks for
the other .so files (libaprutil.so.x and libaprutil.so). It will also drop a
.la file into the install area, but that isn't a big deal.

If aprutil is used in a non-install scenario (e.g. built within another
source tree, such as Apache), then the use of libtool is not a problem as
long as the embeddor also uses libtool. If the embeddor does *not* use
libtool, then it will be best for them to simply not embed, but to
build/install, then refer to it; another option is to refer directly to the
.a or .so files in apr-util/.libs/. I've used both of these methods for
embedding a libtool-based library within an app, and both work quite fine.

The big reason for libtool is to build shared libraries. If it were not for
that, then I'd be with you all the way and punt it! :-)


Greg Stein, http://www.lyra.org/

View raw message