[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Binary compatibility broken? between 3.3.1 and 3.3.2
From:       Thiago Macieira <thiago.macieira () kdemail ! net>
Date:       2004-12-02 20:13:35
Message-ID: 200412021813.42964.thiago.macieira () kdemail ! net
[Download RAW message or body]


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

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]