On Thu, Jun 26, 2008 at 05:10:40PM -0700, Russ Allbery wrote: > "Joe Smith" <[EMAIL PROTECTED]> writes:
> > If the change is a define in a header, where said define is *not* used > > in the library itself, then the libraries binary will not change. Thus > > physically it would have the same API and ABI. > If the new behavior of the header file is required for the new foo > function to be called correctly, then the ABI of foo changed and the > SONAME needs to be increased. > The ABI of a library is not only the the signatures of its exposed > functions but also how the arguments are interpreted. If the > interpretation of an argument changes in a non-backward-compatible > fashion, that's an ABI change. My understanding from reading this thread is that the signature of the function did *not* change, but that in previous versions of the library the macro definition in the header was simply broken, with the result that anything built using that definition would not work correctly. So it sounds to me like there's no ABI change here, just a header bugfix. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
