Reinhard Tartler <[email protected]> writes: > On Mon, Jun 20, 2011 at 12:47:55 (CEST), Kostya wrote: > >> On Mon, Jun 20, 2011 at 11:42:34AM +0100, Måns Rullgård wrote: >>> Kostya <[email protected]> writes: >>> >>> > On Mon, Jun 20, 2011 at 11:36:34AM +0100, Måns Rullgård wrote: >>> >> Kostya <[email protected]> writes: >>> >> >>> >> > On Mon, Jun 20, 2011 at 12:21:43PM +0200, Reinhard Tartler wrote: >>> >> >> That change broke ABI, so we need to recompile all applications >>> >> >> --- >>> >> >> libswscale/swscale.h | 4 ++-- >>> >> >> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >> >> >>> >> >> diff --git a/libswscale/swscale.h b/libswscale/swscale.h >>> >> >> index b0ad912..24b447d 100644 >>> >> >> --- a/libswscale/swscale.h >>> >> >> +++ b/libswscale/swscale.h >>> >> >> @@ -29,8 +29,8 @@ >>> >> >> >>> >> >> #include "libavutil/avutil.h" >>> >> >> >>> >> >> -#define LIBSWSCALE_VERSION_MAJOR 1 >>> >> >> -#define LIBSWSCALE_VERSION_MINOR 1 >>> >> >> +#define LIBSWSCALE_VERSION_MAJOR 2 >>> >> >> +#define LIBSWSCALE_VERSION_MINOR 0 >>> >> >> #define LIBSWSCALE_VERSION_MICRO 0 >>> >> >> >>> >> >> #define LIBSWSCALE_VERSION_INT >>> >> >> AV_VERSION_INT(LIBSWSCALE_VERSION_MAJOR, \ >>> >> >> -- >>> >> > >>> >> > Why major version? IMO minor version bump is enough. >>> >> >>> >> A few external interfaces changed from long to int, which is a major >>> >> break. >>> > >>> > For some reason we don't have rules for ABI change, except for this >>> > abstract >>> > in developer.texi: >>> > >>> > Incrementing the second component means backward compatible change >>> > (e.g. addition of a function to the public API or extension of an >>> > existing data structure). >>> > >>> > Just my can of paint... >>> >>> This change isn't binary compatible on all systems. >> >> Obviously, but should we define that in rules or not? Originally nobody cared >> about binary form distribution at all. > > We do care about binary form distribution since the 0.5 release. If we > didn't we could as well leave release alone completely. > > Ronald elaborated on irc a bit more. The thing is that on architectures > such as x86 (both 32 bit and 64bit), the stack element size is fixed,
Does x86_64 use 8-byte stack slots even for 32-bit parameters? > which maintains alignment. This means that here, all is just > fine. However, as I understand Måns, we do support also other > architectures, where this property is not maintained and therefore, > applications will crash horribly. I don't remember the details of every ABI, and it's possible none of them are in fact affected by this particular change. Many of those with different-size int and long pass those arguments in a register where it wouldn't matter. That said, I'd rather not take any chances. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
