GNOME Bugzilla – Bug 727017
Strategy for binary compatibility from 1.2 to 1.4
Last modified: 2014-06-05 21:27:01 UTC
Should binary compatibility be maintained from 1.2 to 1.4, here are my inputs and concerns on that matter. There are readily binary incompatible changes in codecparsers: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst-libs/gst/codecparsers/gsth264parser.h?id=af78b45979564035ce4f2535d7257201112f776b http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst-libs/gst/codecparsers/gsth264parser.h?id=529ece338fcefd8291e09d6d3fe66357df13078f (etc.) I can bear with the changes, since I always include a local copy into gstreamer-vaapi. But I just wanted to point out the issue in case this affects others. The more general problem I see is that, even if new fields are added at the bottom of a data structure, this yields an incompatible binary change. Imagine for instance that GstH264SPS is allocated on the stack, new fields get added to the end, but the app is not rebuilt. So, we end up overwriting stack while parsing. In theory, this is not a situation specific to -bad codecparsers, but this can be of general concern. A change in a data structure is always an ABI change. The only generic way to circumvent that is to either bump the SONAME of the library, or add some sort of versioning to the data structures. The latter approach is totally unconvenient and visually ugly. The former is simple but needs the user apps to be rebuilt.
In gst-plugins-bad, we never guarantee compatibility, so it is generally not safe to use libraries from -bad outside of it. In core and -base, we always guarantee compatibility, so that means that we only add fields at the end of structures that are never stack allocated and otherwise we put padding at the end of the structure for future extension. This is documented at: http://gstreamer.freedesktop.org/documentation/