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

Re: Summary of C++ symbols experience

Chow Loong Jin <hyperair@debian.org> writes:
> On 29/01/2012 06:20, Russ Allbery wrote:

>> 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).

Yeah, this is another problem with trying to maintain a stable ABI without
SONAME changes in C++.  Inline functions are used *much* more than they
are in C, but you aren't ABI-compatible if significant changes happen in
thoes functions.

> 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).

What I'm seeing (I think; I'm not positive) is that an inline function
(generally inlined because it's defined inside the class definition, not
due to explicit keywords) appears and disappears from the export list of
the library essentially at random with minor changes in the g++ version.

Note that this itself is not actually a real problem with the ABI provided
that functions aren't changed to be inline when they weren't before.  The
external export of the inlined function appears to not actually be used by
clients in the cases that I'm seeing; the disappearance doesn't appear to
cause problems.  What it does cause problems for is use of the symbols
mechanism for versioning dependencies and checking ABI stability.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: