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