Package Details: lib32-x264 157.r72db4377-1

Git Clone URL: (read-only)
Package Base: lib32-x264
Description: Open Source H264/AVC video encoder (lib32)
Upstream URL:
Licenses: GPL
Conflicts: lib32-libx264, lib32-libx264-10bit, lib32-libx264-all
Provides: lib32-libx264,
Replaces: lib32-libx264, lib32-libx264-10bit, lib32-libx264-all
Submitter: GordonGR
Maintainer: ljmf00
Last Packager: droidman
Votes: 34
Popularity: 0.254070
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 »

JonnyJD commented on 2015-08-10 10:02

Now reported here (previus bug tracker not used by x264 team):

JonnyJD commented on 2015-08-09 23:41

Problem reported upstream:

JonnyJD commented on 2015-08-09 20:18

@GordonGR: fully updated Arch Linux and the same commit as in the PKGBUILD from AUR? That sounds strange.

GordonGR commented on 2015-08-09 19:31

It built here properly :-S

JonnyJD commented on 2015-08-09 19:16

Copied info from AUR 3:

With some Arch Linux package update this package broke and compilation gives this error message:

yasm -I. -I. -DARCH_X86_64=0 -I./common/x86/ -f elf32 -Worphan-labels -DSTACK_ALIGNMENT=32 -DPIC -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/x86/predict-a.o common/x86/predict-a.asm
In file included from ./common/common.h:1014:0,
from encoder/me.c:28:
encoder/me.c: In function 'x264_me_search_ref':
./common/x86/util.h:130:5: error: 'asm' operand has impossible constraints
./common/x86/util.h:193:5: error: 'asm' operand has impossible constraints
<builtin>: recipe for target 'encoder/me.o' failed

I can reproduce the problem, but I don't know how to fix the problem.
I also don't know what exact package update made the problem appear.
Either I made a mistake while testing package updates or gcc and gcc-libs are not the problem. Yasm is also the same version since 2014.

I somehow don't get my verification mail for the videolan bugtracker,
but I will try to file a bug there.

The error message is in a file that is exclusively used for 32 bit.
If anybody has an up to date 32 bit arch linux system to test I would like to know if 32 bit really is part of the problem or the way we compile 32 bit on 64 bit machines.

GordonGR commented on 2015-07-28 09:49

Sorry, I had forgotten to enable notifications, I just saw the comments. I still don't like the "-d" thing, but I understand. The issue is at "pacman -Syu", actually. Once you get past that, then you build the lib32-equivalent and you're done. Thank you for your good work.

GordonGR commented on 2015-07-28 09:47

“…yes, 32/64 bit difference is handled automatically…”
Cool! :-D

JonnyJD commented on 2015-07-27 20:17

summary from AUR 3 comments:

Package in [extra] switched to an unstable repository and the referenced commit isn't available upstream anymore.
Reported for [extra] here:

I also had a look at the logs and found an equivalent commit in the stable repository -> updated/fixed PKGBUILD for lib32-libx264

remussatala commented on 2015-07-26 15:01

fatal: Cannot update paths and switch to branch 'makepkg' at the same time.
Did you intend to checkout 'e6d2a36bb' which can not be resolved as commit?

JonnyJD commented on 2015-07-21 19:13

I fixed dependencies (+lib32-glibc, and we now provide "".
Other packages can depend on this and makepkg automatically converts this to a versioned 32 bit (yes, 32/64 bit difference is handled automatically) dependency for the binary package.

While this is a bit of a hassle for users (they have to use the d flag)
it is advisable to use a versioned dependency.
The package breaks if the versioned dependency breaks. No reason to hide that.

This is different to a versioned dependency "libx264" for lib32-libx264:
This doesn't break the actual package, but using the package to build other packages breaks.
(we currently don't force a versioned dependency for libx264)