Hi, On Thu, Jan 17, 2013 at 2:15 AM, Reinhard Tartler <siret...@gmail.com> wrote: > On Thu, Jan 17, 2013 at 11:11 AM, Martin Storsjö <mar...@martin.st> wrote: >> On Thu, 17 Jan 2013, Reinhard Tartler wrote: >> >>> On Wed, Jan 16, 2013 at 7:08 PM, Ronald S. Bultje <rsbul...@gmail.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> On Jan 16, 2013 10:01 AM, "Justin Ruggles" <justin.rugg...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On 01/16/2013 12:46 PM, Ronald S. Bultje wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Jan 16, 2013 9:43 AM, "Luca Barbato" <lu_z...@gentoo.org >>>>>> <mailto:lu_z...@gentoo.org>> wrote: >>>>>>> >>>>>>> >>>>>>> On 16/01/13 11:46, Luca Barbato wrote: >>>>>>>> >>>>>>>> From: "Ronald S. Bultje" <rsbul...@gmail.com >>>>>> >>>>>> <mailto:rsbul...@gmail.com>> >>>>>>>> >>>>>>>> >>>>>>>> Signed-off-by: Luca Barbato <lu_z...@gentoo.org >>>>>> >>>>>> <mailto:lu_z...@gentoo.org>> >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Rebased and compile-tested on arm and powerpc. >>>>>>>> >>>>>>> >>>>>>> Will be pushed in a while if nobody is against it. >>>>>> >>>>>> >>>>>> I had a question for Justin: the prefix is avpriv_, so is order in >>>>>> context part of abi? What about size? >>>>> >>>>> >>>>> I'm not completely sure. The header is not installed so it's not public, >>>>> so the only question I think is with mixing non-matching library >>>>> versions. >>>> >>>> >>> >>> avpriv matches av* and thus is part of the exported symbols. >>> Therefore, adding such a symbol warrants bumping minor (not major). >>> please do that before pushing. >>> >>> mixing non-matching library version becomes interesting when you bump >>> major. However, since all those symbols get proper symbol versions >>> attached nowadays, this is no problem either. >> >> >> It's not all that simple - the point here is that they're adding new fields >> in a private struct (which is used in the implicit private ABI between lavu >> and the others in this case) inbetween existing members. This means that an >> old lavc that tries to use members from the floatdsp context in a newer lavu >> will end up getting the wrong members. > > In that case, that's not private ABI. In fact, that term seems very > wrong, either it something is part for the exposed interface or it is > not. The difference here is that we do not expect applications and > applications outside of libav to inteface them. Which may be fine, but > hardly an excuse to sloppy on binary compatibility. If it breaks ABI, > and there is no way around it, we need to bump major. > >> If the members are added at the end, there shouldn't be too much of an issue >> though. > > If that works, then that's clearly preferable to bumping major!
It changes size of the struct, thus embedding the struct in another struct (in another lib) will break when mixing library versions. To fix this, I believe we need a avpriv_alloc_floatdsp_context() function (or something else that is able to calculate the size of avfloatdspcontext at runtime, within libavutil). Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
