Re: [Boost-build] Boost library naming scheme

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-21 11:47:57

On Monday 21 April 2008 18:23:46 Rene Rivera wrote:
> Vladimir Prus wrote:
> > On Monday 14 April 2008 09:52:31 Rene Rivera wrote:
> > 
> >>> 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.
> >> Given all that, and these:
> >>
> >> a) The Boost ABI is *never* guaranteed stable across *any* two versions. 
> > 
> > This is insane. If 1.35.0 and 1.35.1 are not fully compatible, there's no
> > sense whatsoever for point releases from the stable branch.
> 
> Right. To me the most sense would be to get rid of the patch number.
> 
> >> And is almost always certain to be different based not just on version 
> >> but compiler and compilation options. (For the simple reason that much 
> >> code in Boost is conditionally selected based on all those factors)
> >>
> >> b) That, as far as I understand, the lib*.so.X.Y.Z arrangement is to 
> >> allow for selection among possibly compatible ABIs.
> >>
> >> c) That because of (a) we want to prevent the application of the 
> >> heuristics that support (b).
> > 
> > This is fairly backward. The soname trick works good enough for Linux, and
> > Boost is really not that unique. Boost is only unique is the self that we
> > have vocal Windows community that force ABI issues on the world ;-)
> 
> Well true, we have a Windows community that wants things as easy as 
> possible. But that doesn't really apply here. What applies is that we 
> want a single naming convention for Unix and non-Unix platforms. And 
> since some platforms, yes Windows, don't work with stuff after the type 
> extension (SO, DLL, etc) that only leaves putting the version number 
> before the extension.

We don't want to force the single naming convention on packagers, 
I don't think.
 
> And in case I'm misinformed... The mechanics of (b) that I understand is 
> that specifying a partial version will make the linker search for the 
> closest matching library. And that specifying a complete version, the 
> linker will fall back to a latter patch revision if the one asked for is 
> not found.

I don't think this is true. At link time, the linker will find exactly
the library named on linker command line, but will record the soname,
not the actual library name, inside the executable. At run time, linker
will search with a library that has the name exactly matching soname.
IIUC, there's no special meaning for those version names to the linker.

- Volodya