Re: [boost] building shared boost libraries

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 20:43:33

----- Original Message -----
From: "Steve M. Robbins" <steven.robbins_at_[hidden]>

> > > Suppose then that the next "foo" release changes the ABI.  Then the
> > > shared object must change SONAME.  For example, it may be in a file
> > > named "libfoo.so.2.0.0", with a SONAME of "libfoo.so.2".  None of the
> > > existing binaries using foo will be disturbed, but new programs can be
> > > linked against the new ABI.
> >
> > I suppose these things are encoded into the library file? How?
>
> The details vary by platform.  Hence the insane libtool shell script.  In
> the case of linux, it is done by specifying "-Wl,-soname -Wl,libfoo.so.1"
> at the linking stage.

Oh, an ld flag. That's easy enough to add. It doesn't seem to vary by
platform, but by toolset, from the evidence above. In any case, there's no
reason we can't do that (and in fact you can get it to happen for any of the
boost libraries without changes to the build system).

> > > I gather from the list archives that the auto-* tools were considered
> > > but discarded long ago.  I guess that jam is going to have to be
> > > taught all the things that libtool knows about building shared
libraries.
> >
> > How hard can that be (he says glibly about a 5000-line shell script)?
> > Seriously, though: how many details /are/ there to get right? As arcane
as
> > jam code can be, it's lots more expressive than shell script. I think it
> > should be possible to duplicate this logic in far less code.
>
> Perhaps.  Alternatively you could just have jam invoke it, on the
> systems that libtool supports.

Yeah; I'm just afraid that it won't offer enough control and integration
with Boost.Build. If it does, it might be a good idea to use it.

For example, in Boost.Build, information flows both up and down the
dependency graph. An executable that depends on a shared library that
depends on another shared library will acquire all the relevant
LD_LIBRARY_PATH information for both the direct and indirect library
dependencies. When you run the executable through Jam, everything gets set
up right. I'd worry that libtool will hide the dependency of the
intermediate library on the latter one from me. Maybe these fears are
unfounded and I should just think of it as a linker, though.

> And note also that if you build a shared lib, then want to use it for
> regression testing, you have to do lots more magic (typically involving
> LD_LIBRARY_PATH, but again it varies by platform) to have it run before
> the library is installed into its canonical location.

I know that; we do that.

> That's another part
> of why libtool is so hairy: it has bits to support several different
> things:
>
>       clean           remove files from the build directory
check
>       compile         compile a source file into a libtool object
check
>       execute         automatically set library path, then run a program
check
>       finish          complete the installation of libtool libraries
nope
>       install         install libraries or executables
nope
>       link            create a library or an executable
check
>       uninstall       remove libraries from an installed directory
nope

We haven't considered installation too much yet, but it's in the works.

Is libtool really the answer to everything on platforms where it's
available? If libtool is such a general build/installation tool, does it
handle executables also? If it does everything so well, why do people use
other tools? I just want to get a balanced sense of its place in the world.

-Dave