Re: [Boost-build] Boost library naming scheme

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-21 08:07:49

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:
$ readelf -d /usr/lib/libperl.so.5.8.8

Dynamic section at offset 0x119504 contains 26 entries:
0000000e (SONAME)                     Library soname: [libperl.so.5.8]

> Now you see that "-lfoo" doesn't have any version info.  Generally we
> assume that client code doesn't care whether it links to version
> 1.3.32 or to version 1.3.31.  So the filename part before the ".so"
> should NOT have version info in it.  The Boost Way is that we have to
> use "-lfoo-1.3.32", which is a nuisance for distributing client code
> because you can't know what the user has on his/her system (hence the
> cry for pkgconfig support [1]).

Yes, the filename part before .so need not have the version.

> > So that, if you build against 1.35.0, and then upgrade to 1.35.1,
> > your applications still work.
> 
> So long as a library with the SONAME embedded in your application
> binary still exists, the application works.  As background, you should
> understand that Debian places each shared library in its own package,
> with the library SONAME embedded in the package name.
> 
> There are two cases.
> 
> First, if the upgrade is an ABI change (change of SONAME), then the
> new library lives in a package that can be co-installed with the old
> package.  The old library package is therefore unaffected by the
> upgrade and the application continues to work.
> 
> Second, if the upgrade conserves the ABI (same SONAME), then the new
> library binary overwrite the old.  But maintaining SONAME implies
> strict ABI equivalence, so your application still continues to work.
> 
> The SONAME is the ABI identifier.
> 
> Given what I had said above, you may now be wondering how the 1.35.0
> and 1.35.1 libraries have the same SONAME.  Most libraries use a
> Major.Minor.Revision numbering and guarantee ABI compatibility at the
> Major version level (some at the Minor version level).  The library is
> then named something like libfoo.so.1.35.0 with a SONAME of
> "libfoo.so.1".  Remembering the algorithm of the run time loader, we
> then also need a symlink libfoo.so.1 --> libfoo.so.1.35.0.  And for
> the link time file, we have a symlink libfoo.so --> libfoo.so.1.35.0.

Yes, that's the scheme that I understand as being the usual one.

> > 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?
> 
> I'm not sure.  While many libraries guarantee ABI compatibility across
> micro versions, it's not universally the case.  The only real
> difference is how frequently the SONAME changes as the SONAME is
> the ABI identifier.
> 
> This is a small issue and vendors like Debian can deal with frequent
> SONAME changes.  I'd rather have that than deal with bugs caused by
> accidental ABI changes.  C++ is notoriously hard to audit for ABI
> changes.
> 
> The larger issues are that Boost embeds the boost version and compiler
> name into the library name.  I'd really prefer to address these first.

Well, I surely can keep the current soname scheme for a bit -- effectively
meaning that 1.35.0 and 1.35.1 will be different Debian packages.

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

> 1. Remove the compiler name.
> 2. Remove the Boost version name.
> 
> I'm going to do #1 for Debian's 1.35.0 packages in any case, but
> having explicit upstream support for this is way better.

BTW, please see my another email where I suggest some specific change.

- Volodya