Bug 204990 - [patch] multimedia/x265: update to 1.8
Summary: [patch] multimedia/x265: update to 1.8
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
URL:
Keywords: patch, patch-ready
Depends on:
Blocks:
 
Reported: 2015-12-03 10:38 UTC by Anton Saietskii
Modified: 2016-02-02 21:51 UTC (History)
1 user (show)

See Also:


Attachments
patch for update (1.48 KB, patch)
2015-12-03 10:38 UTC, Anton Saietskii
koobs: maintainer-approval+
Details | Diff
stage & qa-log (10.28 KB, text/plain)
2015-12-03 10:39 UTC, Anton Saietskii
no flags Details
revised patch for update (3.80 KB, patch)
2015-12-03 14:19 UTC, Anton Saietskii
vsasjason: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Saietskii 2015-12-03 10:38:40 UTC
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.
Comment 1 Anton Saietskii 2015-12-03 10:39:02 UTC
Created attachment 163809 [details]
stage & qa-log
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-03 11:20:35 UTC
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 3 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-03 11:21:06 UTC
Comment on attachment 163808 [details]
patch for update

Port is unmaintained, implicit approval
Comment 4 Anton Saietskii 2015-12-03 14:19:34 UTC
Created attachment 163816 [details]
revised patch for update

Included bump for deps.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-03 14:22:15 UTC
Nice work Anton, thank you
Comment 6 commit-hook freebsd_committer 2015-12-05 09:15:58 UTC
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
Comment 7 Jan Beich freebsd_committer 2015-12-05 09:18:01 UTC
Committed. Thanks.
Comment 8 Mikhail Teterin freebsd_committer 2016-02-02 18:05:28 UTC
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?
Comment 9 Jan Beich freebsd_committer 2016-02-02 21:30:05 UTC
(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
Comment 10 Mikhail Teterin freebsd_committer 2016-02-02 21:40:22 UTC
(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?..
Comment 11 Mikhail Teterin freebsd_committer 2016-02-02 21:44:49 UTC
(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...