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

[Michael Niedermayer]

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.
In some sense the problem with symbol moving is a regression cause by
enabling versioning.

Also, once we know how to solve this in the future the solution might be
applicable here too.

Without fixing ldso, the most reasonable if i didnt forget any sideeffects
is to keep the symbols duplicated in the old lib under #if. This would
lead to ld linking code randomly to old / new. Is this a actual problem?
Speaking of this, have you
confirmed that your "half-fix" is linking to new and not old independant of
lib order ?


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20100608/73cad19c/attachment.pgp>