|
|

06-27-2008, 01:10 AM
|
|
|
Handling macro change in an exported library header
"Joe Smith" <unknown_kev_cat@hotmail.com> 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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|

06-27-2008, 01:17 AM
|
|
|
Handling macro change in an exported library header
On Thu, Jun 26, 2008 at 05:10:40PM -0700, Russ Allbery wrote:
> "Joe Smith" <unknown_kev_cat@hotmail.com> 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/
slangasek@ubuntu.com vorlon@debian.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|

06-27-2008, 01:37 AM
|
|
|
Handling macro change in an exported library header
Steve Langasek <vorlon@debian.org> writes:
> 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.
Ah, yes, in that case there's no library SONAME change, just a bug that
may have propagated into other packages in the archive.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|

06-27-2008, 03:32 PM
|
|
|
Handling macro change in an exported library header
* Russ Allbery [Thu, 26 Jun 2008 17:08:56 -0700]:
> Nikita Youshchenko <yoush@debian.org> writes:
> >> If the expr had a bug and old binaries didn't work with the old library
> >> then I would say that requires and shlibs bump, possibly a versioned
> >> conflicts against all rdepends and binNMUs.
> > As far as I understand, as soon as source uses the affected macro,
> > binary is broken if compiled against unfixed version of the library,
> > regardless of what library (fixed or unfixed) it links against at
> > runtime.
> In that case, the ABI did actually change, and the SONAME needs to be
> increased.
> The SONAME doesn't have to be increased only if existing binaries compiled
> with the old library will continue to work with the new library.
Existing binaries compiled with the old library continue to work just
the *same* against the new library; with "just the same" being: bogusly.
(Just remember it's a pre-processor macro that had the bug, not the
library itself.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
When all is summed up, a man never speaks of himself without loss; his
accusations of himself are always believed; his praises never.
-- Michel de Montaigne
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
All times are GMT. The time now is 02:43 AM.
VBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org
|