On Saturday 2022-07-23 15:28, Nicolas George wrote: >Jan Engelhardt (12022-07-23): >> >> This is a follow-up to a topic that was already raised earlier, >> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html >> >> The same has now happened to 5.0->5.1. > >I do not see an issue. What issue do you see?
As I have previously explained, [ http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265705.html ] >"""A program may have been built with 4.3 but is combined >with 4.2.3 at runtime, then this can happen:""" (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 Now, it was clear that >"""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. libavformat.v advertises a verdef (that one being "LIBAVUTIL_59" currently), but you keep modifying the set of symbols, such as dropping avio_vprintf. Minus that bug, libavformat.v is but used to do symbol visibility. For which you don't need a verdef, for starters. diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v index fb17058df5..54dbc84e9a 100644 --- a/libavutil/libavutil.v +++ b/libavutil/libavutil.v @@ -1,4 +1,4 @@ -LIBAVUTIL_MAJOR { +{ global: av*; local: _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
