On Saturday 2017-06-03 14:02, Hendrik Leppkes wrote: >On Sat, Jun 3, 2017 at 1:58 PM, Jan Engelhardt <jeng...@inai.de> wrote: >> >> 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. > >And if you try to run it, it crashes, because its unsupported. I don't >see the issue here. It won't run either way.
You are incorrect, sir. Such a program/ffmpeg combination would refuse to load from the get-go. Which is miles better than crashing somewhere later in the game like it currently does. Which is what I am aiming at... not having it crash. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
