Created attachment 265127 [details] Upgrade to 4.1 The earlier attempt to upgrade to 4.0 was scrapped due to incompatibilities introduced into the API. Upstream have should have addressed these problems in 4.1. Tested on amd64, armv7, and aarch64 (thanks to fuz@ for access to the last two). However, because of extensive use of assembly and some high-profile dependents, an exp-run may be warranted too.
Maintainer informed via mail
Is there a changelog for this update?
(In reply to Robert Clausecker from comment #2) > Is there a changelog for this update? Release notes can be found here: https://x265.readthedocs.io/en/master/releasenotes.html
powerpc64 needs -DENABLE_ALTIVEC:BOOL=false or a non-default option to enable it. Altivec code unconditionally uses VSX.
(In reply to Piotr Kubaj from comment #4) That sounds reasonable. OP, please also look into why the nasm dependency should at all be needed on non-x86. The NASM assembler can only assemble x86 code, so I don't see why it would be needed on anything else.
(In reply to Piotr Kubaj from comment #4) > powerpc64 needs -DENABLE_ALTIVEC:BOOL=false The new version replicates -- or tries to replicate -- the current logic, which enables ALTIVEC on powerpc64le, but not on plain powerpc64. Is that incorrect? Should the decision be based on the content of ${MACHINE_CPU}? I don't have access to a powerpc system myself, so I cannot test :( > The NASM assembler can only assemble x86 code Nasm is also used on both ARM platforms (armv7 and aarch64) -- this hasn't changed from the current version of the port...
(In reply to Mikhail Teterin from comment #6) > Nasm is also used on both ARM platforms (armv7 and aarch64) -- this hasn't changed from the current version of the port... That's super weird... it definitely does not assemble code for these two platforms. Did you test if it would fail to build without nasm installed?
(In reply to Robert Clausecker from comment #7) > it definitely does not assemble code for these two platforms. Actually, you're right! It is looking for nasm at configure-time: -- Found nasm: /usr/local/bin/nasm (found version "2.16.03") but is not actually using it -- cc is used to compile the .S files... Which means, the current port-version is incorrect adding nasm to BUILD_DEPENDS too :-) I'll make the change together with the powerpc64-changes (if any), thanks!
In any case, after extensive build tests I can confirm that x265-4.1 builds with all dependent ports.
Any progress? I'm almost complete with my current batch of build tests and would like to move on.j
(In reply to Robert Clausecker from comment #10) > Any progress? I'm still hoping, piotr@ would let me access a powerpc machine to test on the platform... Shall we wait for a few more days?
(In reply to Mikhail Teterin from comment #11) It's easier if you just provide your proposed patch and then have him report if it works or not. I don't think he gives other people access. If we commit something that doesn't work, pkubaj will just go ahead and patch it anyways, so don't worry about it too much.
Created attachment 265388 [details] Be sure, nasm-dependency is limited to i386 and amd64 architectures
(In reply to Mikhail Teterin from comment #13) This still has the ENABLE_ALTIVEC bits pkubaj mentioned. See comment 4. Note that this is a runtime issue, not a build time issue (older PPC machines don't have VSX), so access to a PPC box will not help you diagnose it.
reply to Robert Clausecker from comment #14) > This still has the ENABLE_ALTIVEC bits pkubaj mentioned. See comment #4.(In I think, I replicate the Altivec-logic in the current version of the port -- see Comment #6. I also suspect, the code performs run-time detection of CPU-features -- at least, on other platforms it does. Unfortunately, without being able to test on a platform, I cannot be sure.
(In reply to Mikhail Teterin from comment #15) Please just follow the guidance from comment #4 and either disable this flag or make it a non-default option. Access to a real machine won't help as the platform Piotr has actually supports these instructions, whereas older PPC platforms may not, so you won't be able to find out if it's a problem or not. When in doubt you can always test with QEMU.
Created attachment 265398 [details] Upgrade to 4.1, with ALTIVEC-option on powerpc*
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0c4cab0453d778353fdec3e01f071536f32c3d5a commit 0c4cab0453d778353fdec3e01f071536f32c3d5a Author: Mikhail Teterin <mi@FreeBSD.org> AuthorDate: 2025-11-13 17:23:47 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2025-11-22 16:01:28 +0000 multimedia/x265: upgrade from 3.6 to 4.1 Unlike with the 4.0, there should be no API compatibility problems. Changelog: https://x265.readthedocs.io/en/master/releasenotes.html Reviewed by: pkubaj PR: 290764 multimedia/x265/Makefile | 88 ++++++++++++-------------------- multimedia/x265/distinfo | 6 +-- multimedia/x265/files/patch-arm-assembly | 9 ---- multimedia/x265/files/patch-warnings | 23 ++++++--- multimedia/x265/pkg-plist | 2 +- 5 files changed, 53 insertions(+), 75 deletions(-)
Thank you for your contribution.