[FFmpeg-devel] ABI break in 4.3

James Almer jamrial at gmail.com
Sun Jul 5 20:21:13 EEST 2020


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.


More information about the ffmpeg-devel mailing list