Re: Handling macro change in an exported library header

["Joe Smith" <unknown_kev_cat@hotmail.com>]

"Bernhard R. Link" <brlink@debian.org> wrote in message 
[🔎] 20080626152905.GA11440@pcpool00.mathematik.uni-freiburg.de">news:[🔎] 20080626152905.GA11440@pcpool00.mathematik.uni-freiburg.de...
> * Nikita Youshchenko <yoush@debian.org> [080626 11:51]:
> > To fix #486693, I need to apply a patch that changes #define'd macro in 
> > an
> > exported library header.
> >
> > The pattern is:
> >
> > extern int foo(char *param1, int param2);
> > #define bar(param) foo(param, expr(param))
> >
> > and changed thing is expr(param)
> >
> > Looks like binary interface of the shared library does not change, 
> > however
> > strictly saying any user of the library that uses bar() macro needs to
> > recompile his code.
>
> I think the relavant questions are: what is semantically changing:
My thoughts:

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. However, the convience API 
would change. So the end applications would need to be recompiled to take 
advantage of this, but since either version of the binary of the library 
would work with these recompiled apps. So the library should not be changed, 
but the programs recompiled, and a warning added to readme.Debian warning 
that locally compiled programs must be recompiled with the new headers.


However if the library itself used the macro, then it has a true API change, 
and must be SONAME bumped.