[lsb-discuss] LSB conf call notes for 2007-11-21

[Jeff Licquia]

Alexey Khoroshilov wrote:
> Actually the problem concerns all C++ libraries containing inline 
> virtual methods.

Ah, yes; inline virtual methods.  We've had this problem before (bug 1173).

At the time, the whole concept of inline virtual methods confused me; 
how could you do such a thing?  But I've learned differently since then.

> The reasoning of this 'or' condition is as follows. If an inline virtual 
> method becomes an equivalent noninline virtual method it does not break 
> backward C++ ABI compatibility. Applications compiled with the old 
> version of a library will work on systems with the new version. So LSB 
> have to permit such changes.

This was the part that confused me before; would the transition from 
inline to non-inline break the ABI?  But you're right; since the vtable 
is a product of the shared library, the change is backward-compatible. 
Older code simply will not use the vtable entry, whatever it contains.

As you say, we should be prepared for implementations to un-inline the 
method at any moment, so the solution you propose makes sense.