For example can I add new function in header file without the need to recompile all programs using that library?
-
Rule of thumb: adding is allowed but removing isn't. – cadaniluk Sep 27 '16 at 14:02
-
To the header *only*? – Eugene Sh. Sep 27 '16 at 14:07
-
1@Downvoter is correct, but I'd add that the important issue is that every exported symbol should remain exported and pointing to exactly the same data type, i.e. do not change the signature of your existing functions. – John Griffin Sep 27 '16 at 14:07
-
2Time to read about [***Semantic Versioning***](http://semver.org). – Jonathon Reinhart Sep 27 '16 at 14:16
-
Also have a look at http://stackoverflow.com/questions/8794964/abi-compatibility-header-library-cross-check – Tali Sep 27 '16 at 14:27
2 Answers
You can add functions and objects to a shared library without breaking existing programs that rely on that library. Under some circumstances you could increase the size of objects (in particular, arrays) in the library.
You can also replace the implementation of a function, provided that the function signature does not change. This will not cause any problems with dynamic linking, but if the new implementation's behavior does not meet existing programs' expectations then you'll see program misbehavior.
You can remove functions and objects that no program links to. If you're concerned only with existing programs then you may be able to catalog what functions and objects those are, but otherwise you can only base such an evaluation on the visibility of the functions / objects within the shared library -- externally-visible functions and objects cannot safely be removed.
There may be other implementation-specific details of a shared library that can be changed without breaking compatibility as well.
Note, however, that none of that has anything directly to do with header files. Compatibility of shared libraries is primarily a run time consideration. Header files are relevant only at compile time.

- 160,171
- 8
- 81
- 157
Another point is that you have to be very careful of any shared structures. If a function in your library accepts or returns a structure or a pointer to a structure, and if you make any changes to that structure (adding, removing, or rearranging members), you're likely to introduce incompatibility.
(Strictly speaking, changes like this do count as changes to the function's signature, as mentioned by others.)
If you're very, very careful, you can arrange to add new members at the end of a structure, but it generally requires explicit cooperation by callers, using mechanisms defined in advance (that is, adhered to since version 0, by all calling code, before any changes get made).

- 45,437
- 7
- 70
- 103