[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5

[Baptiste Coudurier]

On 6/8/10 6:00 PM, Michael Niedermayer wrote:
> On Wed, Jun 09, 2010 at 12:59:18AM +0100, M?ns Rullg?rd wrote:
>> Reinhard Tartler<siretart at tauware.de>  writes:
>>
>>> On Tue, Jun 08, 2010 at 20:44:41 (CEST), Michael Niedermayer wrote:
>>>
>>>> On Tue, Jun 08, 2010 at 04:41:19PM +0200, Reinhard Tartler wrote:
>>>>> On Mon, Jun 07, 2010 at 10:20:45 (CEST), Reinhard Tartler wrote:
>>>>>
>>>>>> On Mo, Jun 07, 2010 at 10:02:19 (CEST), M?ns Rullg?rd wrote:
>>>>>>
>>>>>>> Reinhard Tartler<siretart at tauware.de>  writes:
>>>>>>>
>>>>>>>> On Mo, Jun 07, 2010 at 08:02:54 (CEST), Reimar D?ffinger wrote:
>>>>>>>>
>>>>>>>>> On Mon, Jun 07, 2010 at 07:52:11AM +0200, Reinhard Tartler wrote:
>>>>>>>>>> void av_init_packet(AVPacket *pkt) av_weak_alias(av_init_packet);
>>>>>>>>>> void av_init_packet(AVPacket *pkt)
>>>>>>>>>> {
>>>>>>>>>>      av_log(NULL, AV_LOG_WARNING, "diverting av_*_packet function calls to libavcodec. Recompile to improve performance\n");
>>>>>>>>>>      av_init_packet(pkt);
>>>>>>>>>
>>>>>>>>> ff_internal_init_packet() and add one such to lavc.
>>>>>>>>> Either way, we should make sure we have a solution the next time.
>>>>>>>>> Since the @LIBAVFORMAT version is not accepted in lavc, does that
>>>>>>>>> mean no matter what we do, we will always break ABI if we move code?!
>>>>>>>>
>>>>>>>> if I understand you correctly, you not only consider ABI breakages
>>>>>>>> between releases, but also between any svn revision? Then I fear yes.
>>>>>>>> However, the break is already there since quite some time, and fixing it
>>>>>>>> to have it compatible to ffmpeg 0.5 has (or at least should have)
>>>>>>>> priority, IMO.
>>>>>>>
>>>>>>> For the 0.6 release possibly.  For trunk I don't think that is
>>>>>>> important.
>>>>>>
>>>>>> Agreed. Still, I'd prefer to not do drastic measures in 0.6 like
>>>>>> prematurely bumping soname or something. How do people feel to apply my
>>>>>> propsed "half-fix" to 0.6 only, and bump soname in trunk?
>>>>>
>>>>> The discussion on this thread was very vivid but has now ended rather
>>>>> abruptly, and this question remains unanswered.
>>>>>
>>>>> Does anyone object to have this "half-fix" in 0.6 now, and leave it an
>>>>> open issue for trunk until we either have found a better fix or bumped
>>>>> SONAME? If someone needs more time to think about this, please say so.
>>>>
>>>> i have no awnser atm but i have a question
>>>> how do we move symbols in the future from lavf->lavc / lavc->lavu ?
>>>> this is something we have to do occasionally, and bumping soname is imo
>>>> not reasonable for this.
>>>
>>> I agree that it is pretty annoying, but I don't think it's unreasonable.
>>
>> It seems to be an unavoidable effect of the symbol versioning.
>> Considering that symbol versioning solved an actually observed
>> problem, that this issue has not yet been fingered in the wild, and
>> that symbol moves like this are in fact quite rare, I agree with this
>> assessment.
>
> stefano just moved the eval code from lavc to lavu
> so i dont know, maybe we are just unluky to already have teh second
> such move but it doesnt feel all that rare to me

mm_support will also be moved from lavc->lavu soon probably.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org