[Xcb] [PROPOSAL] how to solve ABI/API issues when fixing protocol definition bugs

[Mark Kettenis]

> From: Christian Linhart <chris at DemoRecorder.com>
> Date: Sun, 10 Jan 2016 12:35:26 +0100
> 
> 2. ABI compatibility
> 
> ABI compatibility is more important than API compatibility because
> it affects end users that install new versions of XCB libraries on an
> existing system. If ABI compatibility is violated, then applications
> will stop working or will work in erroneous ways.

I'd argue that in an open source world, API compatibility is just as
important as ABI compatibility.  The ability to recompile applications
on newer versions of an OS is important on systems where there are
only limited guarantees on ABI compatibility between OS releases.

> To ensure ABI compatibility I propose to use symbol versioning.

Not going to fly, because:

> * Do all of our platforms support symbol versioning?
>    I know that Linux does, but what about Cygwin, etc?

Not all platforms support symbol versioning the way Linux does.  And
some don't support it at all.  Symbol versioning as you know it is
strongly tied to the ELF executable binary format.  So platforms that
don't use ELF, such as OS X and Windows/Cygwin, probably don't support
it at all.

Solaris, which AFAIK is the OS that invented symbol versioning, does
not allow you to export multiple versions of a symbol.  That is, you
*cannot* have both name at XCB_1_12 and name at XCB_1_13.  That feature is a
GNU extension.  And it requires support from the dynamic linker.  So
even systems that use the GNU toolchain don't necessarily support it.
That is the case on OpenBSD for example.  FreeBSD and NetBSD might be
affected too.  In fact I think some of the alternative libc's on Linux
(musl, bionic) don't support it either.

We (OpenBSD) are not planning to implement Linux-style symbol
versioning.  We consider the "binary compatibility forever" approach a
serious security hazard because it allows people to keep old buggy
code around and leads to accumulation of cruft in your shared
libraries.  Instead we try to provide an easy way for our users to
upgrade their systems to a new version of the OS with freshly compiled
binaries.  Hence my different view on API compatibility ;).

The only portable way to handle ABI compatibility is to bump the major
number of the shared library whenever you break the ABI.

Cheers,

Mark