Created attachment 163808 [details] patch for update There is a new version. Official changelog isn't available, but there are many commits to repo from 1.7. NOTE: Library name has been changed, so UPDATING entry should be added or portrevision bumped. Unfortunately, I don't know how to determine exact list of dependent ports including optional deps. Tested build and ffmpeg linking on 10.2R amd64.
Created attachment 163809 [details] stage & qa-log
Thanks Anton, You can grep the ports tree for x265 references, paying particular attention to those (but not necessarily 'only' those) that LIB_DEPENDS on it. If you can update any references identified, and include those changes in your diff, that would be greatly appreciated
Comment on attachment 163808 [details] patch for update Port is unmaintained, implicit approval
Created attachment 163816 [details] revised patch for update Included bump for deps.
Nice work Anton, thank you
A commit references this bug: Author: jbeich Date: Sat Dec 5 09:15:42 UTC 2015 New revision: 403038 URL: https://svnweb.freebsd.org/changeset/ports/403038 Log: multimedia/x265: update to 1.8 ABI isn't compatible, so bump PORTREVISION in consumers. PR: 204990 Submitted by: Anton Sayetsky <vsasjason@gmail.com> Changes: head/graphics/libbpg/Makefile head/multimedia/avidemux/Makefile head/multimedia/ffmpeg/Makefile head/multimedia/gstreamer1-plugins-x265/Makefile head/multimedia/vlc/Makefile head/multimedia/x265/Makefile head/multimedia/x265/distinfo head/multimedia/x265/pkg-plist head/x11/xpra/Makefile
Committed. Thanks.
I have the upgrade to 1.9 complete, and am curious about the ABI incompatibility claimed in this earlier upgrade. How did you conclude, the ABIs are incompatible? Was this determination based simply on the shared library's number, or something else? The number would go up again in 1.9 -- from 68 to 79, but I do not believe, a revision bump is warranted for all dependencies based merely on that. Suggestions?
(In reply to Mikhail Teterin from comment #8) > Was this determination based simply on the shared library's number, or something else? The number represents ABI stability promise by upstream. Most modern build systems like autotools or cmake embed it into SONAME via ld(1). After phasing out a.out support our ld.so(1) only supports tracking major version. However, a small number of ports have neither SONAME nor .so -> .so.MAJOR symlink. Those are "allowed" to crash after updates. # hypothetical scenario with no bump in ports r403038 $ ffmpeg Shared object "libx265.so.59" not found, required by "libavcodec.so.56" $ readelf -d /usr/local/lib/libx265.so | fgrep SONAME 0x000000000000000e (SONAME) Library soname: [libx265.so.68] For more complex cases there're tools like devel/abi-compliance-checker e.g., symbols cannot be removed unless they're loaded on demand (dlopen + dlsym). # libx265.so.59 libx265.so.68 in libmap.conf(5) $ ffmpeg /usr/local/lib/libavcodec.so.56: Undefined symbol "x265_api_get_59" https://people.freebsd.org/~jbeich/compat_reports/x265/1.7_to_1.8/compat_report.html
(In reply to Jan Beich from comment #9) > ld.so(1) only supports tracking major version A rather unfortunate state of affairs, I must say... A library version number could be bumped for two unrelated reasons: to signal addition of NEW functionality, to signal incompatible changes in OLD functionality. In the former cases there is no ABI incompatibility and the already compiled binaries can start use the new library -- but with only the major numbers there is no way to distinguish the two cases... > Undefined symbol "x265_api_get_59" Argh, yes, indeed. A deliberate attempt by the vendor to prevent usage of newer library with the older executables. From x265.h: /* Force a link error in the case of linking against an incompatible API version. * Glue #defines exist to force correct macro expansion; the final output of the macro * is x265_api_get_##X265_BUILD (for purposes of dlopen). */ #define x265_api_glue1(x, y) x ## y #define x265_api_glue2(x, y) x265_api_glue1(x, y) #define x265_api_get x265_api_glue2(x265_api_get_, X265_BUILD) I see the same x265_api_get_79 now in 1.9. I wonder, if the port should patch the sources to avoid this nonsense in the future?..
(In reply to Mikhail Teterin from comment #10) > I wonder, if the port should patch the sources to avoid this nonsense in the future?.. Replying to myself -- unfortunately, we can't do that -- there are some changes in the data-structures. Unlike, say, Apache project, who take care to only add fields at the ENDS, x265 developers are not concerned with compatibility... I'll submit a new PR asking for an exp-run...