Package Details: lib32-x265 3.5-2

Git Clone URL: https://aur.archlinux.org/lib32-x265.git (read-only, click to copy)
Package Base: lib32-x265
Description: Open Source H265/HEVC video encoder. 32bit libraries.
Upstream URL: https://bitbucket.org/multicoreware/x265_git
Licenses: GPL
Provides: libx265.so
Submitter: llde
Maintainer: llde
Last Packager: llde
Votes: 11
Popularity: 0.000168
First Submitted: 2017-08-24 18:30 (UTC)
Last Updated: 2022-02-18 14:42 (UTC)

Required by (24)

Sources (1)

Latest Comments

1 2 3 Next › Last »

TTsdzb commented on 2024-02-04 08:00 (UTC)

lib32-libnuma is now an orphan package. Please use another dependant instead.

Piscolero commented on 2023-11-10 10:09 (UTC) (edited on 2023-11-10 10:13 (UTC) by Piscolero)

cmake should be called with -G "Unix Makefiles" to fix problems if someone (like me) changed the default generator.

Or even better use cmake --build and cmake --install to be independent of generators at all.

llde commented on 2022-02-18 14:44 (UTC)

I included Kae1zae6ai,ahmubashshir and DDoSolitary suggestions. Sorry for the radio silence

Kae1zae6ai commented on 2022-01-20 08:30 (UTC) (edited on 2022-01-20 10:23 (UTC) by Kae1zae6ai)

In PKGBUILD, the line:

depends=('x265' 'lib32-gcc-libs'  'lib32-numactl')

should be changed to:

depends=('x265' 'lib32-gcc-libs'  'lib32-libnuma')

ahmubashshir commented on 2021-07-28 13:20 (UTC)

@Rojikku, @llde
makechrootpkg builds the package properly after applying this patch.

Rojikku commented on 2021-06-02 21:14 (UTC)

It appears that installing this package with aurto or aur sync, which happens in a chroot, resulted in x265.pc not being properly inserted into the PKG CONFIG dir. I had to manually makepkg -sri the PKGBUILD in order to get that file, in order to bu ild lib32-ffmpeg, in order to build lib32-gst-plugins-bad. I would appreciate if this got fixed, but if not, record of this issue is here for those who have the same issue.

DDoSolitary commented on 2021-03-31 15:53 (UTC)

It seems that simply adding git to makedepends fixes the problem. source/cmake/Version.cmake does the version check, and it will read x265Version.txt (which is already available) only when it finds the git executable: https://bitbucket.org/multicoreware/x265_git/src/f0c1022b6be121a753ff02853fbe33da71988656/source/cmake/Version.cmake#lines-51

DDoSolitary commented on 2021-03-27 07:55 (UTC) (edited on 2021-03-27 08:13 (UTC) by DDoSolitary)

The new v3.5 package unexpectedly builds a static library.

$ pacman -Qpl lib32-x265-3.5-1-x86_64.pkg.tar.zst
lib32-x265 /usr/
lib32-x265 /usr/lib32/
lib32-x265 /usr/lib32/libhdr10plus.so
lib32-x265 /usr/lib32/libx265.a

According to source/CMakeLists.txt line 676: # shared library is not installed if a tag is not found. So I would suggest using the git source as extra/x265.

thaewrapt commented on 2021-03-24 12:42 (UTC) (edited on 2021-03-24 12:45 (UTC) by thaewrapt)

Build was successful when I've tried the method @Nocifer mentioned. The other variant (not tested) is to get releases from bitbucket download page: https://bitbucket.org/multicoreware/x265_git/downloads/

EDIT: noticed that the package have migrated from the "bitbucket downloads" not so long ago, so it may not be the working scenario.

Nocifer commented on 2021-03-23 16:51 (UTC)

x265 has been updated to v3.5 as of a week ago, which means that trying to build the recently updated lib32-gst-plugins-bad fails at the moment when lib32-x265 v3.4 tries to link with the updated x265 v3.5 library.

Also, do note that while x265's Github mirror is yet to be updated, the original source link still works after a bit of tweaking, like so (this snippet is taken directly from the main x265 package):

_tag=f0c1022b6be121a753ff02853fbe33da71988656
source=(git+https://bitbucket.org/multicoreware/x265_git#tag=${_tag})

In other words, AFAIU, it's not that the bitbucket link has stopped working, it's just that for some reason the tagged releases have been removed, so this package should instead be using cherry-picked commits from the git repo that correspond to the versioned releases, just like the main x265 package does.

1 2 3 Next › Last »