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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-01 14:19:37

On Sunday 09 March 2008 00:00:35 Steve M. Robbins wrote:

Hi Steve,

[CC for convenience, reply to list please]

> 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

Why should we have the version number twice, both in name
and soname? 

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

I surely can add whatever new naming scheme you want. I guess the question
I have now are:

1. Why the version name is present twice?
2. Do you really need to encode variants in the name, like "mt"? Why
are you building all possible variants?

- Volodya