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

[Michael Niedermayer]

On Sun, Jun 06, 2010 at 11:40:19PM +0100, M?ns Rullg?rd wrote:
> 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.

marking one as weak symbol might work.
weak symbols are part of the ELF spec ... doesnt mean gnu tools support
them of course ;)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20100607/30402623/attachment.pgp>