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

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

On Sunday 06 April 2008 07:29:52 Steve M. Robbins wrote:
> On Tue, Apr 01, 2008 at 10:19:37PM +0400, Vladimir Prus wrote:
> > On Sunday 09 March 2008 00:00:35 Steve M. Robbins wrote:
> 
> > > 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? 
> 
> Actualy, we shouldn't; I was simply following current Boost
> convention.  The more canonical unix convention is:
> 
> 	libfoo.so.X.Y        (soname libfoo.so.X.Y)

In case of Boost, both filename and soname include X.Y.Z. The question
is wether it's OK, of if we should have only two versions in soname. So
that, if you build against 1.35.0, and then upgrade to 1.35.1, your
applications still work.

I think that de-facto, changes between micro versions are very conservative,
so such a compatibility is true, but then, we better raise the matter of the
Boost developers mailing list and have this compatibility promise officially
confirmed. Shall I post?

> 	libfoo.so --> libfoo.so.X.Y
> 
> for version X.Y of library foo.  Then you can link with -lfoo without
> having to specify the version of foo.  
> 
> If we can get both the toolchain and version removed from the link
> libraries, then a major headache goes away;
> c.f. http://svn.boost.org/trac/boost/ticket/1094
> 
> 
> > 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?
> 
> To answer the last question first: Debian packages all possible
> variants because we don't know a priori which variant a user will
> need.  If someone is building boost-using code and is handed a jam
> file that requires libboost_program_options-mt-d-1.34.1.so.1.34.1, we
> should have that available.

I would have hoped that the name of boost library one needs is customizable
in the project needing boost -- otherwise, it won't build with any
other Boost version :-)

 
> Your second question is a good one.  I'm not sure that we need to
> encode variants in the name.  We're just following Boost, here.  I'm
> not aware of any other library that does this to the extent Boost
> does.  Most other libraries are either multithreaded or single
> threaded, but rarely do they come in two flavours.  Also, most
> libraries built with debugging symbols carry the same name rather than
> being decorated with -d, but are put in a different directory.

Yeah, so I guess it might be best, in the long run, to remove the decoration
from the name, and build a smaller set of libraries. 

But one thing at a time -- I guess we better address the solib
naming issue first.

- Volodya