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

Reimar Döffinger Reimar.Doeffinger
Mon Jun 7 00:37:35 CEST 2010


On Mon, Jun 07, 2010 at 12:26:22AM +0200, Michael Niedermayer wrote:
> On Sun, Jun 06, 2010 at 09:01:10PM +0100, M?ns Rullg?rd wrote:
> > Reinhard Tartler <siretart at tauware.de> writes:
> > 
> > > On So, Jun 06, 2010 at 21:51:27 (CEST), M?ns Rullg?rd wrote:
> > >
> > >>> In any case, find below the 'best' fix, that admittedly only works on
> > >>> gnu platforms. Michael, please comment if you prefer the half fix that
> > >>> fixes the issue on gcc/gas platforms (and doesn't regress on others) or
> > >>> bumping major of libavformat.
> > >>
> > >> We _already_ have a regression, which we unfortunately didn't discover
> > >> until now.  Leaving it broken on some platforms while fixing others is
> > >> simply not acceptable.
> > >
> > > Actually, a third way to solve the issue would be to move the affected
> > > symbols back to libavcodec. How about that?
> > 
> > s/libavcodec/libavformat/ methinks.
> > 
> > Not acceptable.  The reasons for moving them to libavcodec still
> > stand.  Some libavcodec interfaces use AVPacket, so the related code
> > must be there too, or we'd end up with a (loose) dependency of
> > libavcodec on libavformat, something we can't have.
> 
> we can duplicate the symbols and code in lavf under #if

Hm, and this can't cause collissions? At least it would have to be
linked only into the .so, not the .a...



More information about the ffmpeg-devel mailing list