Arch Linux User Repository

About GPG, it is up to you to import the missing public key. If you receive an error about it, this is ffmpeg's project public key. Something like the following should do the trick: gpg --recv-keys B4322F04D67658D8

@oxalin

So, looked into it, that is decidedly not the issue. My problem I presume ended up being that I built lib32-x265 using aurto, which should chroot. And something must be wrong with their build process, because my PKG_CONFIG_DIR didn't contain x265.pc, which was needed for this process.

The logs did not indicate this, I just discovered it when I went looking for it after it was mentioned. Logs indicated it was found. (I got help in the IRC)

I will complain on lib32-x265, but the issue was solved by just doing a makepkg -sri of that package manually.

@Rojikku : could it be that your lib32-x265 and your x265 packages are of different versions? The error is usually misleading and pretty useless, but I've seen it before with x265 where the header files (part of x265 package) are from a different version than lib32-x265.

You'll find a trace in one of the log file from the build. Look at MarsSeed's comment from 2021-03-28 about build log src/ffmpeg/ffbuild/config.log

==> Starting build()...
ERROR: x265 not found using pkg-config

For the love of god, why. I've been trying to compile lib32-gst-plugins-bad for like four hours.

I just want to sleep.

I can fix this by hacking the PKGBUILD with some random comments and making the configure script immutable after commenting out the part that allows it to error.

But then I get a very similar error from lib32-gst-plugins-bad so it's moot point. I don't even know if this compiled with x265 support or not.

I tried reading the configure script, and I think it relies on this:

pkg-config --exists --print-errors x265 

Which actually seems to return true perfectly fine on my system, which I confirmed about 50 times in a row before doing a list--all | grep x265 and confirming it's there too.

What do you want from me, ./configure? I even guaranteed I'm not doing it wrong by trying x266 and x267, both of which obviously error.

Please, if anyone knows, tell me. I'm going to crash in bed. This is driving me mad.

@MarsSeed: yes, I've discovered that around the same time you were commenting here. I was relying on an example from ArchLinux' wiki, but without any mention about the epoch. Thanks for notifying me.

I know ffmpeg 4.4 is now available, but I have to wait until ffmpeg package is updated before pushing the appropriate commit. Stay tuned.

@Patola

The PKGBUILD requires git to build properly. https://aur.archlinux.org/packages/lib32-x265/

You could try https://wiki.archlinux.org/index.php/unofficial_user_repositories#archlinuxcn for prebuilt aur binaries. Trusting a 3rd party repo is entirely up to you.

how do I get lib32-x265=3.4? Seems a game on Steam is not working due to the lack of lib32-gst-plugins-bad, which wont compile with lib32-x265=3.5.

@oxalin: Small note, as I've just realised by trying to upgrade only lib32-ffmpeg without also upgrading x264 and x265:

In PKGBUILD's depends version constraint,

depends=('lib32-x264>=0.161')

does not enforce lib32-x264=3:0.160.r3011.cde9a93-4 to be upgraded to 3:0.161.r3039.544c61f-1.

Reason is: because of the epoch value of 3, any 3:V (V: version string) will be higher than 0.160 because the latter is considered as 0:0.160.

You should try to declare your intended version constraint like below:

depends=('lib32-x264>=3:0.161')

@oxalin You wrote:

"As a matter of fact, the native ffmpeg package
doesn't have a version check on these dependencies."

The package might not have that check, but the build config of ffmpeg does have it in case of checking x265 in /usr/lib32:

Quote from my previous build log src/ffmpeg/ffbuild/config.log below (check the command line parameters calling the tests: -L/usr/lib32).

check_func_headers x265.h x265_api_get -L/usr/lib32 -lx265
test_ld cc -L/usr/lib32 -lx265
test_cc -L/usr/lib32
BEGIN /tmp/ffconf.WwFZr5sp/test.c
    1   #include <x265.h>
    2   #include <stdint.h>
    3   long check_x265_api_get(void) { return (long) x265_api_get; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
    6   return ret; }
END /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=native -O2 -pipe -fstack-protector-strong -fno-plt -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-traditional -Wno-unused-but-set-variable -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libmodplug/ -I/usr/include/openjpeg-2.4 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -I/usr/include/srt -I/usr/include/libvmaf -DX264_API_IMPORTS -L/usr/lib32 -c -o /tmp/ffconf.WwFZr5sp/test.o /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--as-needed -Wl,-z,noexecstack -L/usr/lib32 -o /tmp/ffconf.WwFZr5sp/test /tmp/ffconf.WwFZr5sp/test.o -lx265
/usr/bin/ld: /tmp/ffconf.WwFZr5sp/test.o: in function `check_x265_api_get':
test.c:(.text+0xc): undefined reference to `x265_api_get_192'
collect2: error: ld returned 1 exit status
ERROR: x265 not found using pkg-config

@oxalin: You wrote:

"I specifically updated lib32-x265 and lib32-x264 in par to the
native packages prior to updating lib32-ffmpeg's PKGBUILD and
I cleaned out lib32-ffmpeg's build folder to be sure."

-- I will try to do the same, in that order again. (Though that order was the one that I did it the first time and which caused the build-time failures for my lib32-libffmpeg package.)

I suspect that the other way around would be workable though -- first installing the older x264 and x265, then installing the latest lib32-libffmpeg, then upgrading x264 and x265.

@oxalin: Thank you for checking this issue. I've started to have my doubts when I saw that Arch maintainers were able to rebuild the x86_64 version of ffmpeg v4.3.2 against the newer versions of x264 and x265, seemingly without any adaptations on their part.

I will try to do a full rebuild of lib32 versions from AUR PKGBUILDs after making sure I removed the previous versions and cleaned my caches. I use ccache so I will double-check to make sure I cleaned that as well.

Meanwhile I realized that it might be harder to maintain version checks in AUR PKGBUILDs than what binary repo maintainers can do. For each depends=(some_library.so) entry in the PKGBUILD, the makepkg will, during build time, check the installed library file version and hard-code that version in the package tarball - e.g., save it as depends=(some_library.so=1.1) in the .PKGINFO of the binary package.

This same strict locking might not always be viable here on AUR, even less so if dependencies are maintained by different people at different points in time. If a dependency's PKGBUILD does not manually declare provided library versions with something like provides=(somethings.so=1.1), then for the dependant (consumer) package, hard-coding the main pkg version of the dependency is the only other locking option. And that might just be unnecessarily strict and cause more installations to fail due to unsatisfied dependency versions.

I currently use yay, and that seems to not behave too well with strict dependency version locking, even when two or three interrelated AUR packages are selected to be installed as part of the same transaction.*

(*Note: yay can be configured to build all selected AUR packages first, and install them all at once at the end. This could help during install-time, if interrelated, version-locked package dependencies get installed the same time as the dependant (consumer) package. But in that case, if ffmpeg does indeed check already installed library versions in /usr/lib32, then it will have checked the wrong libraries, because they have not yet been updated.)