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 ).
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
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk