Re: [boost] boost dll versions

From: Benjamin Kosnik (bkoz_at_[hidden])
Date: 2005-08-23 11:25:55

> I think it is a bit unfortunate that we don't have a system to determine
> whether boost updates break existing api's.  The usual process is that, for
> example, suppose we have
> 
> libboost.so.1.33.0
> 
> Let's assign this soname libboost.so.1.  Then a symlink is created
> 
> libboost.so.1 -> libboost.so.1.33.0.
>

Symlink is generated via ldconfig on linux, other dynamic loader
machinery on other systems. You can't simply do this link randomly and
expect it to work: it's generated from the way the shared object is
constructed. (Not the way it's named, at least not on all systems.)

> Now if a bugfix comes out that does not change the api, be can have

ABI, not API.

> 
> libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
> 
> libboost.so.1 -> libboost.so.1.33.1

...the rest is largely correct for linux in particular.

The boost build/configure machinery can be made to work with linux conventions. Thanks Rene!

However, boost in the past has not made this kind of interim release. I
realize, after catching up on this list, that they may or may not do
something like 1.33.1 in the future. This kind of minor release would
be welcome, however I wait for it to actually happen before
substantially altering the current RPM strategy.

> OK, so that's the background.  AFAICT, we (boost) don't have any way to tell
> if a new release breaks existing api, and whether to up the version.  I
> think that is unfortunate.  I don't really know what to do about it,
> though.

This is unfortunate.

There is a difference between API and ABI. Not all API changes are ABI
incompatible. 

For the record, there exists some Red Hat testing infrastructure for
the boost rpms. Between 1.32.0-6 and 1.33.0-1, there were substantial
ABI differences. Because of this, the SONAME was bumped in accordance
to existing linux conventions. For those interested, I will attach some
of these results to this email as an attachment.

It is my opinion, as a mere observer and packager, that boost cares not
a wit about compatibility. And you know what? This is fine with me:
these are supposed to be experimental libraries and should not be
constrained, design wise, with the restraints of backwards
compatibility with past (flawed) experiments.

Thus, packagers for each system should determine how this stuff fits
together, and deal with the fallout in a way that they deem sensible.

best,
benjamin