[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of C++ symbols experience

On 29/01/2012 06:20, Russ Allbery wrote:
> Sune Vuorela <nospam@vuorela.dk> writes:
>> On 2012-01-28, Russ Allbery <rra@debian.org> wrote:
>>> 5. It's still not clear that the benefit is worth the amount of effort,
>>>    since I expect most C++ libraries to require frequent SONAME changes
>>>    anyway, which means that the long-term binary compatibility angle of
>> Qt has kept binary compatibility since 4.0 was released in 2005. (and
>> 3.0 kept binary compatibility during the 3.0 series)
>> kdelibs has kept binary compatibility since 4.0 was released in 2007
>> so I wouldn't as such call it 'frequent SONAME changes', but it do
>> require carefulness and commitment from upstream to do it.
> Right, I think Qt is quite possibly the best maintained C++ library of
> significant size out there.  I'm not saying that the benefit isn't worth
> it for fairly well-maintained libraries, *particularly* if they do symbol
> export control, which eliminates much of the churn that I'm seeing
> (although I'm still not sure what the implications of the inlining of
> functions would be).  But I don't think most C++ libraries are like Qt.  I
> could be wrong, I suppose; I don't have wide-ranging experience.

Changing the implementation of an inlined function will require a recompilation
of all third party applications/libraries including the header, unless the
changes don't really matter (new and old implementations are compatible with
each other).

As for the effect of inlining on symbols:
 - A function which is marked as inline, but is not inlined by the compiler
   ends up being exported as a weak symbol. (without -fvisibility=hidden)

 - A function which is both marked as inline, and inlined by the compiler is
   not exported (unless a non-inlined copy of the function exists as well,
   which can happen if you start using function pointers).

While we're on the topic of Qt, they have a great set of guidelines for
maintaining binary compatibility in shared libraries[1], complete with
explanations on why each policy is necessary.

[1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++>

Kind regards,
Loong Jin

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: