Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags

[Reinhard Tartler]

Christophe Mutricy <xtophe at chewa.net> writes:

> 2009/7/14 Reinhard Tartler <siretart at tauware.de>:
>> ------------------------------------------------------------------------
>> r19254 | diego | 2009-06-23 01:09:34 +0200 (Di, 23. Jun 2009) | 3 lines
>>
>> Add ff_ prefixes to exported symbols in libavformat/riff.h.
>
> [...]
>
>>  - mplayer is (yet another time) using internals of libavformat and
>>   therefore very dependent on the exact version of ffmpeg against which
>>   it was compiled against.
>
> Now i'm confused. For me exported = external.

in 'normal' software project, that's correct. For ffmpeg, that
assumption doesn't hold.

there have been symbol visibility patches been proposed in ffmpeg, but
they weren't apply because they broke one thing or another. I agree that
introducing them would be a very good idea, as we could then consider
introducing symbol files for ffmpeg and start tracking symbol additions
and removals.

such a patch would however most probably break applications like mplayer
horribly.

> so it's a break of the API so requires a soname bump.

they differentiate between "external api" and "internal api". Most
obvious example is avutil, where a lot of functions are allowed to be
called from inside other ffmpeg libraries but not outside ffmpeg.

this is "enforced" by defining public symbols and functions only in
"public" headers, headers that are installed with 'make install'. FFmpeg
only guarantees binary compatibility for software using these symbols.

mplayer however contains a private copy of ffmpeg in its sources, and
has therefore no problem including headers that are not
installed. libavformat/riff.h is e.g. such a header. This is strictly
speaking a violation of usage convention, but the mplayer developers
don't care here.

> So if I trust the svn log, it's FFMpeg fault for not bumping soname
> and mot mplayer fault.

it would be indeed easy to avoid this situation, if marillat would
introduce an own soname for his packages. Or if we would introduce
(again) an debian specific soname.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4