Re: [Boost-build] Help deciphering gcc.jam, please

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-03-08 16:00:35

Vladimir,

Thanks for demystifying $(<[-1]:D=) for me.

On Sat, Mar 08, 2008 at 10:00:07PM +0300, Vladimir Prus wrote:
> Steve M. Robbins wrote:

> > If you've read this far: my goal is to remove the compiler-name
> > decoration from the SONAME of the shared libraries.  This decoration
> > causes grief building packages for distributions like Debian.  I do
> > know about --layout=system, but that causes even more grief because
> > the resulting libraries have *no* SONAME at all.
> 
> Hmm, this is highly strange. On SVN HEAD, when I do: [...]

Ooops.  I mis-remembered.  Indeed, --layout=system does give you
SONAME.  However, it gives you a SONAME without any version number,
which is not useful for packaging.

The standard layout for a shared library on linux (and several unix
variants) uses several files.  For a library like boost that
guarantees no compatibility between releases, there are two files:

1) The shared library itself

        libboost_program_options-mt-1.34.1.so.1.34.1
        (soname: libboost_program_options-mt-1.34.1.so.1.34.1)

2) A symbolic link to (1) for linking

        libboost_program_options-mt-1.34.1.so

Notice that everything appearing in the file name and soname are
intrinsic to the library.  The compiler used is not intrinsic and
causes integrators like Debian a lot of grief.  So I want to get
rid of it.

While we're on the topic, let's address --layout=system.  This
produces a library without the version number.  The attraction of this
naming is that the build system for client code doesn't have to guess
or be told the version number to link.  However, the version number is
vital to integrators so that multiple shared library versions can
coexist on the system.  The way out of this dilemma is to introduce
the simplified name as a third symbolic link:

3)	libboost_program_options-mt.so --> libboost_program_options-mt-1.34.1.so

Right now, neither --layout addresses our needs.  The default
versioned layout is closest; I simply need to hack it to get rid of
the compiler version.  The symlinks for (2) and (3) we produce outside
of the boost build system, which is a bit of a nuisance, but not the
end of the world.  Ideally, I'd like to propose that bjam itself
produce them upon installation.

Cheers,
-Steve