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

List:       kde-devel
Subject:    Re: KDE ABI stability?
From:       Dan Kegel <dank () kegel ! com>
Date:       2005-12-05 15:20:42
Message-ID: a71bd89a0512050720j7442bbb9j8242f773b47ec752 () mail ! gmail ! com
[Download RAW message or body]

On 12/5/05, Thiago Macieira <thiago@kde.org> wrote:
> Hmm... the gcc manual says gcc 3.2 and 3.3 share the same C++ ABI.

Thanks for the correction.  (There are some ABI fixes in 3.3, but only
for non-x86 chips, I think.)

Your current text about gcc's abi,

>If the internal ABI-interface of the compiler changes, a library
compiled with a
>different version might no longer be possible. The following GCC-releases
>are known to have a different ABI-interface for C++:
>    * GCC 2.95.x
>    * GCC 2.96.x (RedHat)
>    * GCC 3.0.x / 3.1.x
>    * GCC 3.2.x / 3.3.x (GCC ABI v1)
>    * GCC 3.4.x / 4.0.x / 4.1.x (GCC ABI v2)

is good, but has three problems: 1) it doesn't mention the ABI standard
that gcc is trying to comply with, 2) an ABI isn't an internal thing,
3) ABI-interface is redundant, as the I means interface already.  How about:

Binary compatibility depends on a stable ABI from the compiler.
GCC's c++ ABI changed with each of the following releases:
    * GCC 2.95.x
    * GCC 2.96.x (RedHat)
    * GCC 3.0.x / 3.1.x
    * GCC 3.2.x / 3.3.x (GCC ABI v1)
    * GCC 3.4.x / 4.0.x / 4.1.x (GCC ABI v2)
As of gcc-3.2, Gcc follows the
[http://www.codesourcery.com/cxx-abi multivendor C++ abi],
so binary compatibility is not determined by the version of
the compiler, but by the version of the ABI it supports.


--
Why can't Johnny run Linux?  See http://kegel.com/linux/comfort
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]