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

Jan Engelhardt jengelh at inai.de
Sat Jun 3 14:58:06 EEST 2017

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

More information about the ffmpeg-devel mailing list