You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2000/12/02 22:54:53 UTC
use of libtool (was: Re: cvs commit: apr-util/test .cvsignore Makefile.in)
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! :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: use of libtool
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 02, 2000 at 02:59:03PM -0800, rbb@covalent.net wrote:
>...
> > Nope. The .so files are standard .so files. Anybody can use and link against
> > them, just like every other .so file.
>
> Okay, my comments came from reading the libtool manual,
Hey... nobody can dis you for reading the manual. Most of us don't. :-)
> but if you have real-world experience with this,
Insofar as working on Subversion for the past five/six months, which also
uses libtool. That wouldn't be a big deal, but I had to wrestle with
integrating Neon and Expat(-lite) into the build, and figuring out how to
properly set up the linking against those (embedded) libs. The other
suicide-inducing involvement with libtool was trying to get a module built
and installed into Apache (as both static-link and dynamic-load). The latter
is why I believe Apache could possibly simplify module writers' experiences
by using something that only builds DSOs (rather than full shared libs).
> lets just use libtool.
Coolness.
Any other concerns out there, people?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: use of libtool
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 04, 2000 at 11:42:06PM +0100, Branko Cibej wrote:
> Greg Stein wrote:
>...
> > Sure, we'd get it to work on Linux and *BSD. Possily a Solaris and AIX box.
> > But the rest? Eek.
>
> You're an optimist. AIX already gets a few eeks from me. Non-ELF
> platforms are mostly goblins. :-)
Oh, I completely agree with you. But we'd end up with AIX support because a
good number of Apache/APR developers are at IBM and they keep the AIX stuff
running properly.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: use of libtool
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> 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.
+1 on using libtool. I have the same experiences as Greg here -- an
embedder can always use the files in .libs. Let's not reinvent the wheel
here.
> Sure, we'd get it to work on Linux and *BSD. Possily a Solaris and AIX box.
> But the rest? Eek.
You're an optimist. AIX already gets a few eeks from me. Non-ELF
platforms are mostly goblins. :-)
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: use of libtool
Posted by rb...@covalent.net.
> > 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.
Okay, my comments came from reading the libtool manual, but if you have
real-world experience with this, lets just use libtool.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: use of libtool
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: use of libtool (was: Re: cvs commit: apr-util/test .cvsignore
Makefile.in)
Posted by rb...@covalent.net.
> > > 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
-------------------------------------------------------------------------------