Re: [Boost-build] Boost library naming scheme

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-04-14 00:43:49

Steve M. Robbins wrote:
> On Sun, Apr 13, 2008 at 11:04:35AM -0500, Rene Rivera wrote:
>> Steve M. Robbins wrote:
>>> From Debian's perspective, the name changes we'd like to see are:
>>>
>>> 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.
>> I somehow always end up pointing this out... The compiler is put into 
>> the library name because using different compiler+stdc++ can cause ABI 
>> changes. 
> 
> Yes it can, but often it doesn't.  I'm told, for example, that
> gcc 4.1 and gcc 4.2 are ABI compatible.
> 
>> So I have a simple question about the Debian packaging; What 
>> happens when the compiler version changes in the system but the library 
>> versions do not? Do you recompile all the packages to the new version? 
> 
> Yes.  When a compiler or standard library forces an ABI change, all
> affected packages (libraries and applications) are rebuilt.  This is
> fairly painful for a distribution the size of Debian, but manageable.
> It's mostly transparent to users, except that user code may need to
> be recompiled.

Am I to surmise from below that you change the version numbers of all 
libraries when this happens? Hence forcing users to recompile to account 
for the ABI change?

>> Are users forced to recompile all their code?
> 
> Effectively, yes.
> 
> When Debian rebuilds a library due to an externally-forced ABI change, we
> produce a different package but since both the old and new packages install
> the same library file they must conflict.  In some cases, you can simply
> refuse to install the new library package and continue using your old code.
> However, for a library (like Boost) that is used by other packages, you'll
> quickly be forced to install the new version and rebuild your local code.

Hm... So you also uninstall the older package for the ABI change? If so, 
how do you support binary only, aka commercial, packages? Do you wait 
for the providers to rebuild them? Or are they unusable as soon as the 
user upgrades?

>> Recently I've been thinking that just dropping the association between 
>> the Boost version number and the SO version number is best. Since the 
>> version number is encoded in the library name itself anyway. For a frame 
>> of reference our current scheme follows 
>> <http://boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html#library-naming>:
>>
>>    libboost_qwerty-gcc40-mt-d-1_35.so.1.35.0
>>
>> And dropping the SO version, and replacing it with a fixed release number:
>>
>>    libboost_qwerty-gcc40-mt-d-1_35.so.0.0
> 
> With respect, that's backwards.

Doesn't seem any less backwards, i.e. arbitrary, than putting the number 
only at the end :-)

> The conventional scheme, as I
> outlined, is to put the library version in the SONAME but not in the
> "link name".  That is, (for a single-threaded non-debug variant) the
> library file name (and SONAME) is:
> 
>     libboost_qwerty.so.1.35.0
> 
> while for the linker there is the symbolic link
> 
>     libboost_qwerty.so --> libboost_qwerty.so.1.35.0
> 
> so that you can use "-lboost_qwerty" not caring about what version is
> installed.

Why would it matter at all what the original name of the library is, if 
the point seems to be to only access it as the undecorated name? I could 
as well use:

   n=`mktemp XXXXXXXXX.so`
   ln -s ${n} libboost_qwerty.so

> This is established convention in linux, so I don't understand why
> you'd want to do anything differently.

I know I'm being a pest on this... But I'm not much for unreasoned 
conventional practices. As for the reason it's the way it is... Because 
we want to support about 7 different operating systems with, ideally, a 
single consistent naming scheme. So as to reduce our testing and support 
permutations with the goal of giving users a high quality product. But 
as it stands we have 2 naming schemes at the behest of Linux packagers. 
But that's OK since we are expressly not testing the alternate name 
scheme with the understanding that the packagers are responsible for 
that testing.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail