Jan Engelhardt (12022-07-23):
> As I have previously explained,
> [ http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265705.html ]

Read the replies that have been made to you at the time.

> (Or, in today's terms, a program built with 5.1 but which is
> combined with 5.0 at runtime, then this can happen:
> 
> $ ./a.out 
> ./a.out: symbol lookup error: ./a.out: undefined symbol: avio_vprintf, 
> version LIBAVFORMAT_59

This is a perfectly normal outcome.

> >"""Running against an older version then the build version is never
> >supported
> >
> >A distribution should never allow this to happen."""
> 
> This is exactly what we're trying to do. ELF symbol version definitions 
> are *the* tool to do this, but we keep getting screwed over by terrible 
> symbol version management in ffmpeg.

No, the ELF symbol version system cannot prevent you from replacing a
file with an older version. The tool to prevent that is the package
manager of the distribution, and it obviously depends on the
distribution. With Debian, it looks like that:

Depends: libavcodec59 (>= 7:5.0)

What symbol versioning can achieve at most is turn a dangerous late
incompatibility, such as accessing a field that was added in the new
version, into an immediate harmless crash like the one you quoted above.

> libavformat.v advertises a verdef (that one being "LIBAVUTIL_59" 
> currently), but you keep modifying the set of symbols, such as dropping 
> avio_vprintf.

Please point the commit where we dropped avio_vprintf. It would be a
severe mistake. But to the better of my knowledge we avio_vprintf was
added about a month ago and never dropped, and you are mistaken.

> 
> Minus that bug, libavformat.v is but used to do symbol 
> visibility. For which you don't need a verdef, for starters.

Well, make that your lede instead of a dump of a completely useless
report of so-called incompatibilities reported by a tool that does not
know the specifics.

Even better, submit it as an actual patch explaining why and after
checking it does not break anything else.

Regards,

-- 
  Nicolas George