Package Details: lib32-x264 157.r72db4377-1

Git Clone URL: https://aur.archlinux.org/lib32-x264.git (read-only)
Package Base: lib32-x264
Description: Open Source H264/AVC video encoder (lib32)
Upstream URL: https://www.videolan.org/developers/x264.html
Licenses: GPL
Conflicts: lib32-libx264, lib32-libx264-10bit, lib32-libx264-all
Provides: lib32-libx264, libx264.so
Replaces: lib32-libx264, lib32-libx264-10bit, lib32-libx264-all
Submitter: GordonGR
Maintainer: ljmf00
Last Packager: droidman
Votes: 34
Popularity: 0.235929
First Submitted: 2018-08-18 16:08
Last Updated: 2019-04-09 20:37

Required by (38)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

oxalin commented on 2018-02-16 01:40

Would it be possible for you to extend this PKGBUILD and build the three corresponding "native" packages libx264 libx264-10bit libx264-all?

llde commented on 2017-10-03 12:26

It should use
"git+https://git.videolan.org/git/x264.git#commit=${_commit}"
as source url.

Also using git+https allow people like me that are behind an uncoperative firewall (as university network) to download the package.

GordonGR commented on 2017-03-12 17:08

Apparently, I am the maintainer again… so I took the liberty to remove the pkgver() function. [extra] has it for the convenience of its maintainer, who wants to push versioned releases whenever they need to, and the function just adds a half-fake version number. That is perfectly fine. But this is not [extra]; in the AUR, we update not whenever we need to but whenever the repositories' maintainers do, stepping on their foot steps, in order to keep the lib32- packages on par with their original counterparts. I also made a few simplifications.

JonnyJD commented on 2015-08-18 19:57

It was brought to my attention that `-fstack-check` is now part of the default makepkg.conf so the problem is not exclusive to hardening-wrapper. (fixed the PKGBUILD)

JonnyJD commented on 2015-08-18 18:44

@GordonGR: Hm, no clue where that is coming from. The variable is called "dc" in code and in the function arguments (as such it is declared).
This didn't change in the last commits either.

So the only way I could explain that is a hardware issue on your end. Is your memory completely fine? Or maybe your disk?

Anyways, it doesn't look like a problem with the package.

GordonGR commented on 2015-08-18 18:07

Thank you Johnny.

By the way, the first I tried to build today's version, it failed. When I ran makepkg again with the -L switch to get a full log (and with LANG=C for english), it built properly. Whatever. The initial error message (my translation by hand) is:

encoder/rdo.c: In function ‘quant_trellis_cabac’:
encoder/rdo.c:784:30: error ‘lc’ hasn't been declared (first use in this function
int lastindex = !lc && num_coefs == 64 ? x264_last_coeff_flag_offse
^
encoder/rdo.c:855:5: note in expansion of macro ‘TRELLIS_LOOP’
TRELLIS_LOOP(0);
^
encoder/rdo.c:784:30: note each undeclared identifier is reported only once for each function it appears in
int lastindex = !lc && num_coefs == 64 ? x264_last_coeff_flag_offse
^
encoder/rdo.c:855:5: σημείωση: in expansion of macro ‘TRELLIS_LOOP’
TRELLIS_LOOP(0);
^
<builtin>: recipe for target 'encoder/analyse.o' failed
make: *** [encoder/analyse.o] Error 1

JonnyJD commented on 2015-08-18 17:58

FYI: This is also reported here:
https://github.com/thestinger/hardening-wrapper/issues/6

GordonGR commented on 2015-08-18 17:56

Indeed I have not! Congrats :D

JonnyJD commented on 2015-08-18 17:44

I tracked the problem to
https://www.archlinux.org/packages/community/x86_64/hardening-wrapper/ version 10.
This introduces a default for adding -fstack-check to the CFLAGS (or rather using them hidden, as it is a wrapper).

The updated package disables PIC (and PIE) when hardening-wrapper is installed.

Note that hardening-wrapper is a makedepends for lib32-ffmpeg (an rdep of this package).

@GordonGR:
I guess you don't have hardening-wrapper installed, so you don't have the problem.

GordonGR commented on 2015-08-10 10:07

Well, yes JohnyJD, with a fully up-to-date system, it does build. Apparently I don't have some package you do that interferes. I even waited for my mirror to get on par, because usually it takes half a day. I don't know.

At any rate, I put the newly built package in my Dropbox, in case someone needs it until it gets fixed:
https://dl.dropboxusercontent.com/u/4361965/lib32-libx264-148.20150725-2-x86_64.pkg.tar.xz