[haiku-commits] Re: r35370 - in haiku/trunk: build/jam src/libs/png src/libs/zlib

On 2010-02-01 at 09:11:09 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2010-02-01 at 00:41:45 [+0100], zooey@xxxxxxxxxxxxxxx wrote:
> > Author: zooey
> > Date: 2010-02-01 00:41:44 +0100 (Mon, 01 Feb 2010)
> > New Revision: 35370
> > Changeset: http://dev.haiku-os.org/changeset/35370/haiku
> > 
> > Modified:
> >    haiku/trunk/build/jam/ImageRules
> >    haiku/trunk/build/jam/MainBuildRules
> >    haiku/trunk/build/jam/OptionalPackages
> >    haiku/trunk/src/libs/png/Jamfile
> >    haiku/trunk/src/libs/zlib/Jamfile
> > Log:
> > * reverted the part of r35362 that introduced support for minor ABI
> > versioning - my evil twin made
> > me do that!
> 
> Scary! ;-)
> 
> BTW, "ABI" doesn't sound correct in this context. The ABI is the low level
> specification defining how functions are called, which registers can be used
> for what purpose, how names are mangled, the layout of vtables, etc.

Hm, what you've described are parts of the C++ ABI or the "system" ABI, but 
according to what I've read on the net about shared libraries, the binary 
(compiled) version of their API is referred to as their application binary 
interface (ABI). 
I actually changed the naming because for one of the libs (not sure, but I 
think it was libjpeg), there was mention of one release changing the ABI 
while staying compatible with respect to the API - and we really only deal 
with binary compatibility here.

I am going to play with a couple of abi compatibility checkers in order to 
find one that can help us decide whenever a library update in fact changes 
the ABI (so we can bump the version). Otherwise updating a ported library 
could prove to be a rather difficult job, as (judging by the three libs I've 
checked) the library authors can't be trusted to say something meaningful 
about their ABI versioning scheme.
If I find an ABI checker that works, I'm going to create an optional package 
for it.

cheers,
        Oliver

Other related posts: