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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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

I suspect that might cause a conflict during linking since the same
symbol would be provided by two libraries.  If it doesn't fail, the
version chosen is unpredictable.  We'd end up with apps linked against
a mix of sym at LIBAVFORMAT_XX and sym at LIBAVCODEC_XX which is obviously
not good.

-- 
M?ns Rullg?rd
mans at mansr.com