Re: [boost] building shared boost libraries

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-01-19 17:29:29

On Mon, Jan 14, 2002 at 08:43:33PM -0500, David Abrahams wrote:
> 
> ----- 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. 

Yes, by "toolset".

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

That would be nice.  

It is necessary, though, that the library authors maintain a coherent
version number.  Not knowing any better, I tend to pick the libtool
scheme of CURRENT, REVISION, and AGE.  This is reasonably-well documented
at:
    http://www.gnu.org/software/libtool/manual.html#Versioning

I'm sure it sounds like I'm trying to push libtool on you; I'm not.
It's just that it is the library-building tool with which I am familiar
and the libtool authors have researched shared lib building and
cross-platform issues way better than I have.  It doesn't matter to
me how the libraries are ultimately built.  It matters to me that
they have a workable versioning scheme.

Notwithstanding that, in what follows I'm reverting to libtool
advocacy.  ;-)

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

I suspect the latter is true.

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

Does it build executables that use shared libs?  Yes.

> If it does everything so well, why do people use other tools?

I am not aware of any similar tool in the UNIX milieu.  

Projects that don't use libtool tend to build shared libraries "by
hand", using the compiler and linker.  Why?  I would guess that the
main reasons are: the project pre-dates libtool, wide portability is
not a goal of the project, dislike of libtool, or simple ignorance of
libtool.

I'm virtually certain that any project that does NOT use libtool
will not build shared libs on as many "toolsets" as a project that
does use it.  The reason for this is pretty simple: the libtool team
is focused on tracking all the nuances, bugs and changes in the
various tool sets.  No other project is going to have the same
knowledge they do.

Essentially, libtool is nothing more than an abstraction of the linker.
Abstraction layers are a good thing.  You wouldn't want to give up
the kernel's "device driver" and go back to coding for every possible
variant of serial port hardware.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants