Bug#512844: ffmpeg-debian breaks binary compatibility
Jakub Wilk
Version: 3:0.svn20090119-1
Severity: serious
After upgrading ffmpeg from 0.svn20080206-15 to 3:0.svn20090119-1,
mplayer stopped working:
$ mplayer
mplayer: symbol lookup error: /usr/lib/i686/cmov/libavcodec.so.51: undefined symbol: ff_gcd
$ apt-cache policy mplayer | grep Installed
Installed: 1.0~rc2-20
$ apt-cache policy libavcodec51 | grep Installed
Installed: 0.svn20080206-15
$ ldd /usr/lib/i686/cmov/libavcodec.so.51
linux-gate.so.1 => (0xb7fde000)
libavutil.so.49 => /usr/lib/i686/cmov/libavutil.so.49 (0xb7fc0000)
libz.so.1 => /usr/lib/libz.so.1 (0x4e193000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0x4e150000)
libfaad.so.0 => /usr/lib/libfaad.so.0 (0x4f211000)
libgsm.so.1 => /usr/lib/libgsm.so.1 (0x4f018000)
libtheora.so.0 => /usr/lib/libtheora.so.0 (0x4f501000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x4f116000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x4ef6e000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0x4e178000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0x4dfed000)
/lib/ld-linux.so.2 (0x4dfcf000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x4ede7000)
$ apt-cache policy libavutil49 | grep Installed
Installed: 3:0.svn20090119-1
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (900, 'unstable'), (500, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Gevers
Thanks
The problem is that you are using mplayer from unstable, with ffmpeg
from experimental. The experimental version of ffmpeg-debian creates
libavcodec52, where your mplayer should depend on if you want to use it.
But the ffmpeg in unstable builds/needs libavcodec51, so that is why
mplayer depends on it. You can at this moment not mix ffmpeg from
experimental with mplayer from unstable.
Maybe ffmpeg should conflict with old versions of the libraries, ie
Conflicts libavcodec51, libavcodec-unstripped-51 etc...
Paul
Jakub Wilk
>The problem is that you are using mplayer from unstable, with ffmpeg
>from experimental. The experimental version of ffmpeg-debian creates
>libavcodec52, where your mplayer should depend on if you want to use it.
>But the ffmpeg in unstable builds/needs libavcodec51, so that is why
>mplayer depends on it. You can at this moment not mix ffmpeg from
>experimental with mplayer from unstable.
>
>Maybe ffmpeg should conflict with old versions of the libraries, ie
>Conflicts libavcodec51, libavcodec-unstripped-51 etc...
libavutil soname, as its ABI have changed.
Reinhard Tartler
retitle 512844 ffmpeg libraries need more strict internal dependencies
retitle -1 mplayer must not use ffmpeg internal functions like ff_gcd
stop
Paul Gevers <pa...@climbing.nl> writes:
> Severity: normal
> Thanks
>
> The problem is that you are using mplayer from unstable, with ffmpeg
> from experimental.
close. mplayer in unstable uses ff_gcd, which is a strictly internal
function of libavutil. It has been renamed to av_gcd on Jan, 17, 2009.
Applications like mplayer are not supposed to use such functions. I just
checked mplayer's trunk, at found this commit:
------------------------------------------------------------------------
r28338 | cehoyos | 2009-01-17 12:29:36 +0100 (Sa, 17. Jan 2009) | 1 line
Fix compilation: s/ff_gcd/av_gcd.
> The experimental version of ffmpeg-debian creates libavcodec52, where
> your mplayer should depend on if you want to use it. But the ffmpeg
> in unstable builds/needs libavcodec51, so that is why mplayer depends
> on it. You can at this moment not mix ffmpeg from experimental with
> mplayer from unstable.
>
> Maybe ffmpeg should conflict with old versions of the libraries, ie
> Conflicts libavcodec51, libavcodec-unstripped-51 etc...
yes, we need more strict internal dependencies in ffmpeg, which we
happen to fact to discuss right now. However mplayer mustn't use
internal functions. for av_gcd, this function has just been introduced
in the new ffmpeg version, so updating mplayer to a version later than
28338 will fix this issue.
(or alternatively backport that svn revision to current mplayer)
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reinhard Tartler
> * Paul Gevers <pa...@climbing.nl>, 2009-01-24, 16:03:
>>Maybe ffmpeg should conflict with old versions of the libraries, ie
>>Conflicts libavcodec51, libavcodec-unstripped-51 etc...
> That would be a sane work-around. However, the proper fix is to bump
> libavutil soname, as its ABI have changed.
Well, yes and no.
I've talked to upstream about this yesterday, and the situation is more
complicated. Upstream follows ABI/API changes pretty closely, but only
for the "public" API. The idea is that all functions starting with
"ff_*" are strictly private and may be changed without notice. However
external API is kept private.
I've then asked why not write a linker script to hide the internal
symbols. This isn't possible, because libavcodec is allowed to use
internal symbols of libavutils. They are upstram and know what they are
doing. external programs like mplayer are not. *shrug*
anyway, this means that we cannot guarantee that it is possible to mix
around libav* packages from different snapshot dates. We therefore need
stricter dependencies in the ffmpeg packages. That's what this bug is
about. The other thing is mplayer referencing internal functions. This
has also been fixed upstream by renaming ff_gcd to av_gcd, read: making
it public. Problem solved upstream.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--