On Saturday 2017-06-03 13:34, Hendrik Leppkes wrote: >> >> 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.
I never implied that such should run. >Our ABI is stable in one direction, not in both. No doubt about it; most software holds it that way (including glibc). What I am trying to express here is that this unidirectionality has not been properly expressed in libavcodec.v so far. If avcodec_receive_packet had been in a LIBAVCODEC_57.37 section as proposed, a program built with the 57.37 headers would have a marker "needs '57.37'". But right now, all programs just have "needs '57'", and 57 is also satisfied by ffmpeg 3.0. By placing avcodec_receive_packet into the existing LIBAVCODEC_57 and not into LIBAVCODEC_57.37, the toolchain was essentially told that it is compatible in both directions. That is just how ELF symbol versioning works. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
