Binary compatibility broken? between 3.3.1 and 3.3.2

[Thiago Macieira]

Rex Dieter wrote:
>Couldn't new public symbols be tagged in the shared lib, similar to how
>glibc does it, like:
>libc.so.6(GLIBC_2.1)

glibc does that for multiple versions of the symbols. Not to mark the 
entry of new ones.

>So, this new kdelibs-3.3.2 symbol would generate a dependancy something
>like:
>libkdecore.so.4(KDE_3.3.2)
>
>If it was done this way, binary compatibility would be seemless, and it
>would make packagers' (rpm, deb whatever) life a lot simpler.
>
>IMO, qt could try do to this to, even between qt-x.y -> qt-x.(y+1)
>upgrades, since the shared lib is the same libqt-mt.so.3

It is much easier said than done. We're dealing with C++ here, and not 
everything is easily versioned. Imagine, for instance, versioning the 
virtual table, or the typeinfo. For that matter, remember that C++ 
mandates only one typeinfo, so you can't even think of versioning it.

It would make sense to mark a symbol's entry date to the library, as you 
proposed. That would readily tag a dependency against its minimal 
versions. 

However, not using a newer method doesn't mean you don't require a newer 
behaviour. That could give a false illusion to developers and packagers.
-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041202/2c1be546/attachment.sig>