> On Dec 3, 2016, at 2:10 AM, Richard L. Hamilton <[email protected]> wrote: > > Looks to me like mpv checks at runtime that it is linked with the same > version (regardless of nominal compatibility) of ffmpeg (at least) as when it > was built, and if not, refuses to run: > > ffmpeg library versions: > libavutil 55.34.100 > libavcodec 57.64.100 (runtime 57.64.101) > libavformat 57.56.100 > libswscale 4.2.100 > libavfilter 6.65.100 > libswresample 2.3.100 > ffmpeg version: 3.2.1 > > mpv was compiled against a different version of FFmpeg/Libav than the shared > library it is linked against. This is most likely a broken build and could > result in misbehavior and crashes. > > mpv does not support this configuration and will not run - rebuild mpv > instead. > > Exiting... (Fatal error) > > > Uninstalling it and re-installing it (assuming it's rebuilt, as it was in my > case) fixes it...but is there a way to automate this, so that when ffmpeg is > upgraded, it checks if mpv is installed, and if it is, forcibly reinstalls it? > > >
If that's so, then whoever updates the ffmpeg port to a new version must also increase the revision of the mpv port to rebuild it. A comment could be added to the top of the ffmpeg port, near the version line, to remind that person to do that. The developers of the mpv software should be contacted about relaxing this restriction. It seems a bit much; other software doesn't do that.
