Re: [boost] building shared boost libraries

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-01-14 19:34:20

On Sun, Jan 13, 2002 at 06:52:22PM -0500, David Abrahams wrote:

> > "SONAME" expands to "Shared Object NAME".  Think of it as the label for
> > the application binary interface implemented by a shared library.
> >
> > For example, libfoo.so.1.0.1 might have a SONAME of "libfoo.so.1".
> >
> > Suppose a new "foo" library is released that fixes bugs, but does NOT
> > change the ABI.  The new library could live in a file named
> > "libfoo.so.1.0.2", with the same SONAME "libfoo.so.1".  All the
> > existing binaries linked with the "libfoo.so.1" ABI will transparently
> > start to use the updated library.
> 
> Only, I suppose, if it's put in the right place or the LD_LIBRARY_PATH is
> appropriately updated?

Correct.  My interest is building binary packages for Debian,
which install into "the right place", namely /usr/lib.  The RPM-building
folks are going to have the same need.

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

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

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.  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
      compile         compile a source file into a libtool object
      execute         automatically set library path, then run a program
      finish          complete the installation of libtool libraries
      install         install libraries or executables
      link            create a library or an executable
      uninstall       remove libraries from an installed directory

-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