[FFmpeg-devel] ABI break in 4.3

[Hendrik Leppkes]

On Sun, Jul 5, 2020 at 7:29 PM James Almer <jamrial at gmail.com> wrote:
>
> On 7/5/2020 1:58 PM, Jan Engelhardt wrote:
> >
> > On Sunday 2020-07-05 18:18, James Almer wrote:
> >>>>
> >>>> Won't that break the entire ABI of anything currently linked, and thus would
> >>>> require a major bump?
> >>>
> >>> Since 4.3 was sort of a break over 4.2.3 already
> >>
> >> No, it wasn't.
> >
> > Perhaps not on a high level. But for the ELF system, it was a break,
> > because you used the <SONAME, SYMVER> tuple, specifically <libavcodec.so.58,
> > LIBAVCODEC_58>, with two _different sets of contained symbols_.
> >
> > Was it the reason for blender crash? I do not know that, nor do I know the
> > blender internals, but if it can be ruled out (at the very least, in the
> > future) that version mixup between $buildhost and $userhost can be the
> > cause of present or future crashes in blender or otherwise, I'll be damned if I
> > didn't try.
> >
> > ===
> >
> > The following changes since commit c2d000ec27af1a5cd5341a67e941e0313879ab18:
> >
> >   lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding (2020-07-05 23:43:45 +0800)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/jengelh/ffmpeg master
> >
> > for you to fetch changes up to 3ec24e4e548ecd6d4cc2f11a7d6717548abdadab:
> >
> >   build: do proper ELF symbol versioning (2020-07-05 18:50:58 +0200)
> >
> > ----------------------------------------------------------------
> > Jan Engelhardt (1):
> >       build: do proper ELF symbol versioning
> >
> >  libavcodec/libavcodec.v       | 254 +++++++++++++++-
> >  libavdevice/libavdevice.v     |  28 +-
> >  libavfilter/libavfilter.v     |  78 ++++-
> >  libavformat/libavformat.v     | 185 +++++++++++-
> >  libavresample/libavresample.v |  30 +-
> >  libavutil/libavutil.v         | 555 +++++++++++++++++++++++++++++++++-
> >  libswresample/libswresample.v |  33 +-
> >  libswscale/libswscale.v       |  44 ++-
> >  8 files changed, 1163 insertions(+), 44 deletions(-)
>
> The list of functions is incomplete. After a quick look, you're for
> example missing av_map_videotoolbox_format_* in libavutil.
>
> This is another issue that i don't know if you considered, and that's
> the fact currently some symbols may not present depending on configure
> time options, build environment, and target system. Videotoolbox is of
> course not available for you unless you're targeting OSX.
>
> This afaik can be solved by ensuring they are always present, and
> returning ENOSYS/NULL as required if the actual implementation is not
> compiled in.
> We're doing as much in a few places, but clearly not enough care was
> taken to ensure that's always the case.

I don't think platform specific functionality should get such a
treatment. A build on the same platform should always present the same
ABI, but nothing you can do will make videotoolbox function on Linux
or Windows, so the symbols have no business being included.
Headers for such functionality might even require OS-specific headers
to be included (eg. D3D on Windows, VT on OSX), which if of course not
going to work.

In this case, the ABI is not dependent on configure, but on the
underlying platform you are building on. Of course it should be
corrected if they are purely configure-controlled, and instead perhaps
moved to a platform model.

- Hendrik