[FFmpeg-devel] ABI break between 3.0 and 3.3 without symvers/SONAME changes

[Jan Engelhardt]

On Saturday 2017-06-03 14:02, Hendrik Leppkes wrote:

>On Sat, Jun 3, 2017 at 1:58 PM, Jan Engelhardt <jengelh at inai.de> wrote:
>>
>> On Saturday 2017-06-03 13:34, Hendrik Leppkes wrote:
>>>>
>>>> Fixing the .v file with a patch now won't help remedy the situation on
>>>> existing systems; however, on future patch submissions, this action of
>>>> editing the .v file needs to be remembered when functions are
>>>> added or removed.
>>>
>>>We have always added new functions within the same ABI. If you build
>>>against a newer version and expect it to run against an older version,
>>>its just not going to work.
>>
>> I never implied that such should run.
>>
>>>Our ABI is stable in one direction, not in both.
>>
>> No doubt about it; most software holds it that way (including glibc).
>> What I am trying to express here is that this unidirectionality has
>> not been properly expressed in libavcodec.v so far.
>>
>> If avcodec_receive_packet had been in a LIBAVCODEC_57.37 section as
>> proposed, a program built with the 57.37 headers would have a marker
>> "needs '57.37'". But right now, all programs just have "needs '57'",
>> and 57 is also satisfied by ffmpeg 3.0. By placing
>> avcodec_receive_packet into the existing LIBAVCODEC_57 and not into
>> LIBAVCODEC_57.37, the toolchain was essentially told that it is
>> compatible in both directions. That is just how ELF symbol versioning
>> works.
>
>And if you try to run it, it crashes, because its unsupported. I don't
>see the issue here. It won't run either way.

You are incorrect, sir. Such a program/ffmpeg combination would refuse 
to load from the get-go. Which is miles better than crashing somewhere 
later in the game like it currently does.

Which is what I am aiming at... not having it crash.