[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic