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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100609/e198bd46/attachment.pgp>