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

[Hendrik Leppkes]

On Sat, Jun 3, 2017 at 1:18 PM, Jan Engelhardt <jengelh at inai.de> wrote:
>
> I received a user report about ABI breakage between ffmpeg 3.0 and 3.3
> through the distribution commenting system
> https://build.opensuse.org/package/show/multimedia:libs/ffmpeg :
>
>         """I'm having a library compiled against ffmpeg 3.3 on OBS. It
>         uses the avcodec_{send|receive}packet() functions. On my local
>         machine I still have ffmpeg 3.0 installed. Updating the library
>         doesnt trigger updating libav* since soversion hasnt changed. If
>         the library now attempts to use avcodecsend_packet() I receive
>         SIGBUS."""
>
> I am posting to this list as the "fix" for this problem is not a patch,
> but a change in review process.
>
>
> Upon closer inspection of the ffmpeg source, the problem the user
> has experienced has two causes:
>
>
> 1.
>
> Failure to properly do ELF versioning. avcodec_receive_packet was added
> in commit 7fc329e2dd6226dfecaa4a1d7adf353bf2773726. This commit bumped
> the minor version number, but completely ignored adding the necessary
> versions into libavcodec/libavcodec.v. What should have been added:
>
> LIBAVCODEC_57.37 {
>         global:
>         avcodec_receive_packet;
>         avcodec_send_packet; /* etc. */
> } LIBAVCODEC_57.36;
>
> Instead, all symbols just always get added into a symbol group that
> existed previously (LIBAVCODEC_57). This defeats package management
> utilities like rpm which only look at the symbol groups and not
> individual symbols.
>
> 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.
Our ABI is stable in one direction, not in both. Building against
headers that are newer then your binaries is not supported, and a
rather unusual and odd situation to expect to work, truely.

We're not reponsible for your package mangement problems. We properly
version all our releases and versions, and we don't support running
against an older version then was used at build-time.

The same applies to structs. The size of structs is not  part of the
ABI, and as such we are free to grow it to accomodate new fields
without breaking the ABI.

- Hendrik