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

Hendrik Leppkes h.leppkes at gmail.com
Sat Jun 3 15:17:18 EEST 2017


On Sat, Jun 3, 2017 at 2:07 PM, Jan Engelhardt <jengelh at inai.de> wrote:
>
> 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.

The key is that even if such new function usage would somehow be
prevented, it would still not solve the underlying problem.
If an app would not use those new functions, you would never know it
was incompatible, and it might still crash due to using old headers,
or express any other sorts of subtle bugs. Protecting new functions
only solves one symptom of the issue, not the issue itself.

- Hendrik


More information about the ffmpeg-devel mailing list