Re: Handling macro change in an exported library header
"Bernhard R. Link" <firstname.lastname@example.org> wrote in message
* Nikita Youshchenko <email@example.com> [080626 11:51]:
To fix #486693, I need to apply a patch that changes #define'd macro in
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,
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:
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.