Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Sat, 2 Dec 2000 14:22:29 -0800
From: Greg Stein <gstein@lyra.org>
To: dev@apr.apache.org
Subject: Re: use of libtool
Message-ID: <20001202142228.U12166@lyra.org>
Mail-Followup-To: dev@apr.apache.org
References: <20001202135453.Q12166@lyra.org>
 <Pine.LNX.4.21.0012021402000.1714-100000@koj.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0012021402000.1714-100000@koj.rkbloom.net>;
 from rbb@covalent.net on Sat, Dec 02, 2000 at 02:09:29PM -0800

On Sat, Dec 02, 2000 at 02:09:29PM -0800, rbb@covalent.net wrote:
>...
> > 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 the same as a .so file:

[gstein@kurgan apr-util]$ file .libs/libaprutil.so.0.0.0
.libs/libaprutil.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
[gstein@kurgan apr-util]$

> It is a hack so that the same thing works on all
> platforms.

They do a bunch of stuff to get shared libs working wherever possible. On
platforms that don't support them at all, then some magic occurs. Don't ask
me what because I haven't seen that (because those platforms are relatively
rare nowadays). The libtool manual probably describes this well.

> 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.

Nope. The .so files are standard .so files. Anybody can use and link against
them, just like every other .so file.

> APR is going to need to build a shared library at some point,

Yup. Most definitely. (this is also the basis of some of my complains with
OtherBill's unicode-fs stuff, but I think we worked out what to do)

> 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 think we're going to have to / want to use libtool there, too. libtool
already does it correctly for each platform, and I would *not* be confident
in the slightest of us getting it right. It wouldn't be "a simple shell
script"... I know that much.

Sure, we'd get it to work on Linux and *BSD. Possily a Solaris and AIX box.
But the rest? Eek.

> 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?

Apache 1.3 never builds as a shared library, so I'm not sure whether the
situation is analogous. Note: I wouldn't call it a "workaround". It is
straightforward if your app uses libtool, or you look in apr-util/.libs/ if
you don't use libtool. Nothing fancy or awkward.

Cheers,
-g

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