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.237123
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-07-19 20:33

Thanks.

GordonGR commented on 2015-07-18 12:45

Updated. I also took the initiative to remove (comment out) the highly problematic ">=" and "<" thingies in the depends array that would neither let me "pacman -Syu" nor "makepkg".

FadeMind commented on 2015-07-17 15:05

New libx264 released.

JonnyJD commented on 2015-06-25 13:30

FYI: there is now
https://aur4.archlinux.org/packages/lib32-libx264/

GordonGR commented on 2015-06-24 11:43

Det, because it used to be a category and… I don't know.

GordonGR commented on 2015-06-24 11:42

Johnny, I read your bug report and I see your point. I also agree that, since the package pulls from the stable release, it doesn't matter if it pulls from git or ftp or whatnot, and yes, the [extra] package does the same. (In fact, I had raised that point to gS644, see below, but then I went with it because he had just showed me how to overcome the building difficulties.) When I asked the merge from lib32-libx264 to lib32-libx264-stable-git, the TUs seemed to silently accept the renaming, so, honestly, I'm not sure which is the best name. I will ask aur-general and act according to what they decide.

Det commented on 2015-06-23 22:10

Why "lib32" as a keyword? It's already included in the name.

JonnyJD commented on 2015-06-23 22:02

I don't insist and I do agree that these <=, = etc. are a pain, especially on AUR where fewer things are automated (without additional tools).

In the case mentioned on https://aur.archlinux.org/packages/lib32-ffmpeg/
it is the other way around. libx264 is current and lib32-libx264 is not.


There is a problem regarding the package name as lib32-libx264-stable-git:
The name of the lib32-ffmpeg dependency is still lib32-libx264 (as the it is irrelevant for dependencies if it is from git or whatever). However, on the AUR this breaks any kind of link between lib32-ffmpeg and lib32-libx264-stable-git (on [extra] matching with "provides" works; on AUR it does not).

We have 3 options:
1) Waiting for https://bugs.archlinux.org/task/45443 to be fixed
(best, but this might take a while..)
2) using lib32-libx264-stable-git as package name and as the dependency
(technically wrong, since it is irrelevant how the library is provided (git or whatever))
3) using lib32-libx264 as package name and as the dependency
(I like this most, since the package name is also libx264 in [extra] and that also uses a git repository!)

GordonGR commented on 2015-06-23 19:55

Hello Jonny. Indeed, you have to update foo before lib32-foo. However, libx264 is in version 144 since 2015-03-07 and I only updated in 2015-06-14, three months later (I had missed the update). So I doubt anyone still has the old version. Besides, I truly hate the "=", ">", ">=" thingies as, I believe, cause more problems than they allegedly solve. If you insist, I will put it, but I'd rather avoid it.

JonnyJD commented on 2015-06-23 14:13

You always need to have the same versions of libx264 and lib32-libx264(-stable-git), otherwise you get errors like that:
libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_144'
or
libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_142'

The reason is /usr/include/x264{,_config}.h from libx264 package.

So you might want to do something like
depends=("libx264.so=144-64")