Re: [Boost-build] Boost library naming scheme

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-22 02:59:20

On Tuesday 22 April 2008 06:12:39 Steve M. Robbins wrote:
> On Mon, Apr 21, 2008 at 04:07:49PM +0400, Vladimir Prus wrote:
> > On Sunday 13 April 2008 16:14:23 Steve M. Robbins wrote:
> >  
> > > > 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.
> > > 
> > > First of all, the SONAME is always the same as the library filename.
> > > The reason is this: at link time, the SONAME is embedded into the
> > > binary produced; at runtime, the runtime loader searches for a file
> > > with the name of SONAME.
> > > 
> > > When -lfoo is given at link time, a file by the name of "foo.so" is
> > > sought.  As indicated previously, the convention is that foo.so is a
> > > symlink to foo.so.1.3.32.  In this manner, the SONAME "foo.so.1.3.32"
> > > is embedded in the binary and foo.so.1.3.32 is used at runtime
> > > regardless of what foo.so points to or whether it even exists.
> > 
> > I don't think the above is true, in general:
> 
> No, it's not true in general.  I was speaking in the context of Boost
> where -- because there is no ABI compatibility -- the SONAME has all
> three version components.

Yes, so either we:

1. Drop version from the name, leave the version in suffix only and have SONAME
equal to file name, or
2. Do as above, but decide and micro-versions are ABI compatible, and strip micro-
version from soname.

Sounds right?

> > > > > > I guess the questions 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 :-)
> > > 
> > > But this begs the question.  Why should one have to customize
> > > anything?  The project should just build.  Most other libraries manage
> > > this because they DO NOT embed the version name in the link library
> > > name, i.e. the "-lfoo" part.
> > 
> > Err, I'm asking you why you build all variants, and you say that some
> > project might link to a specific variant, and I suggest that the project
> > might link to some other variant, and you suggest that the project links
> > to libboost_foo? Well, isn't this exactly the same as my original suggestion
> > to build a single variant, without any decoration?
> 
> OK, now I'm totally confused :-)
> 
> Can you build a single variant that is suitable for both
> single-threaded and multi-threaded applications?  If so, why has Boost
> been generating foo.a and foo-mt.a all these years?  Ditto for the
> -d variants.

The -d, I think, is simple. They are generated just in case you need to debug
boost. Not that users are know to routinely do that. I don't think adding debug
options changed ABI. If it does, it's a bug because it means you cannot replace
release library with debug should you need to find a bug, which makes debug
library half useless.

ST/MT variants have the potential to change ABI, and I think some libraries in
Debian have separate -mt package. I think in this age, and given that shared_ptr
has non-locking implementation for popular processors, Boost should be always
built in MT mode, and clients be required to build with -pthread.

- Volodya