Bug#662793: ffmpeg: relocation error, version LIBAVCODEC_53 not defined in file libavcodec.so.53

[Reinhard Tartler]

On Tue, Mar 6, 2012 at 7:05 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> On 12-03-06 at 06:33pm, Reinhard Tartler wrote:
>> On Tue, Mar 6, 2012 at 6:25 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> > On 12-03-06 at 05:51pm, Reinhard Tartler wrote:
>> >> On Tue, Mar 6, 2012 at 2:10 PM, Fabian Greffrath
>> >> <fabian at greffrath.com> wrote:
>> >> > Hi Laurento,
>> >> >
>> >> > Am 06.03.2012 13:54, schrieb Laurento:
>> >> >
>> >> >> I've just upgraded ffmpeg and now it simply doesn't work...
>> >> >> $ /usr/bin/ffmpeg: relocation error:
>> >> >> /usr/lib/x86_64-linux-gnu/libavformat.so.53: symbol
>> >> >> avcodec_is_open, version LIBAVCODEC_53 not defined in file
>> >> >> libavcodec.so.53 with link time reference
>> >> >
>> >> >
>> >> > this symbol has been added in Version 4:0.8-2. Please update your
>> >> > libavcodec53 package to that version as well.
>> >> >
>> >> > Reinhard, how about bumping shlibs when symbols are added? ;)
>> >>
>> >> Ouch, yes, that's indeed a bug in the package and needs to be fixed in
>> >> 4:0.8-3.
>> >
>> > Using symbols files would catch this, causing a build failure until
>> > corrected.
>> >
>> > I offer to add that, if noone objects.
>>
>> I looked into that last year (or the year before). The problem is that
>> symbol files do not seem to support alternative dependencies in a way
>> that allow applications to link either against libav or their
>> libav-extra counterparts.
>>
>> The other problem with symbol files are that libavcodec and
>> libavformat still export too many private symbols. This is being
>> worked on upstream, which is why libav 0.9 will bump SONAMEs again.
>>
>> If you want to implement symbols file without replacing the current
>> shlibs file (which on the first sight seems pretty pointless), then
>> I'd have no objections.
>
> Thanks for elaborating!
>
> I believe the use of symbols files override shlibs, so do not expect to
> be able to support that requirement of yours, even if it did make sense
> (I fail to understand what use that would be).

Mainly sanity checks about exported/dropped symbols. The usefulness
about this might be debatable, since upstream (and I) do extensive
code reviews to ensure compatibility, but another check never hurts.

> I do recall now that in our earlier discussion the main issue was
> private symbols.  Thanks for reminding me :-) Nice to hear that work is
> ongoing on improving that.
>
> Regarding libav-extra I would prefer that source package to be dropped,
> but let's rehash that discussion later... :-)

Ask in a couple of months again. I think there might be a solution
then, but let's see.

-- 
regards,
    Reinhard