apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: use of libtool (was: Re: cvs commit: apr-util/test .cvsignore Makefile.in)
Date Sat, 02 Dec 2000 22:09:29 GMT
> > > 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.

The problem is that a libtool .so file, AFAIK, is not the same as a
regular .so file.  It is a hack so that the same thing works on all
platforms.  I do not believe that libtool .so files work when the program
using them is not using libtool, so this would limit apr-utils usefulness
to just programs using libtool.  I would much prefer to not have that
limitation.

APR is going to need to build a shared library at some point, and I hope
we don't use libtool there either.  I would prefer to invest the
time/energy into just doing this correctly on each platform.  I would
think this could be accomplished with a simple shell script to call the
correct programs from within the Makefiles.

I dislike forcing people to use a work around to embed our library in
their project.  Didn't Apache 1.3 solve this problem once?  Can we
leverage that code?
 
> 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! :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message