Hi, consider a library libabstr implementing an interface and a library libimplX that is currently used by libabstr to actually do stuff. The public headers are called abstr.h and implX.h
libabstr could be designed in basically two different ways:
1: * abstr.h contains just prototypes, perhaps also inline functions that
only call libabstr functions
* libabstr is linked with -limplX
* applications are linked with -labstr
2: * abstr.h contains only inline functions that call libimplX functions
* libabstr is neither built nor linked, libabstr-dev ships a pkg-config
file or similar
* application build process uses pkg-config to determine what to link with
In each case no changes to the source of applications are needed if libabstr
decides to use libimplY instead, in case 1 it may even work without a
rebuild.
Here comes the tricky part:
What shall maintainers of applications using libabstr do if:
* libabstr used to fit way 1
* an inline function in abstr.h now contains:
__asm ("" : : "r" (&libimplX_foo));
so no real calls to libimplX functions are done from the header, but the
application is forced to link with -limplX
* no pkgconfig file or similar is provided
* the change in libabstr was introduced in a debian release
* the breakage from that change is not documented in debian/NEWS
Greetings
Timo
signature.asc
Description: This is a digitally signed message part.
