On 29/01/2012 07:18, Russ Allbery wrote: > 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. That would be caused by changes in the logic that g++ uses to determine whether or not to inline a function that is marked as inline. I believe you can effectively just mark the symbols for all inline functions as optional in the symbols files. > 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. The symbols for inlined functions don't cause problems for clients because they're marked as weak symbols, so they're either inlined in the client code, or the symbol from the client code overrides them. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: OpenPGP digital signature