On Sun, Jul 5, 2020 at 7:29 PM James Almer <jamr...@gmail.com> wrote: > > 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.
I don't think platform specific functionality should get such a treatment. A build on the same platform should always present the same ABI, but nothing you can do will make videotoolbox function on Linux or Windows, so the symbols have no business being included. Headers for such functionality might even require OS-specific headers to be included (eg. D3D on Windows, VT on OSX), which if of course not going to work. In this case, the ABI is not dependent on configure, but on the underlying platform you are building on. Of course it should be corrected if they are purely configure-controlled, and instead perhaps moved to a platform model. - Hendrik _______________________________________________ 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".
