g_module_open() failed: undefined symbol: I422ToARGBMatrixFilter

[SpineEyE]

Hi, today when updating libavif from 0.9.3 -> 0.10.1, an update hook was called that prints this error message:

g_module_open() failed for /usr/lib/libavif.so.14: /usr/lib/libavif.so.14: undefined symbol: I422ToARGBMatrixFilter

The hook calls the following command: /usr/bin/gdk-pixbuf-query-loaders --update-cache /usr/lib/libavif.so.14.

Is this a packaging error or something wrong about the library?

[glitsj16]

Is this a packaging error or something wrong about the library?

I just saw the same error after upgrading libavif on Arch Linux. IMO this is due to an outdated libyuv package in the Arch Linux community repo (a libavif dependency). After changing its PKGBUILD to use commit de71c67e53d79190b5b7cc760ade9027855dd945 (instead of the current 3aebf69d668177e7ee6dbbe0025e5c3dbb525ff2) - see here - and rebuilding both libyuv and libavif the above error went away.

I'll do some more testing before filing a bug on the Arch Linux tracker.

HTH

[wantehchang]

Thank you for the bug report. We try to detect the version of libyuv at compile time before calling I422ToARGBMatrixFilter(). Let me check if that libyuv version test is correct.

[wantehchang]

Here is how libavif v0.10.1 calls the libyuv function I422ToARGBMatrixFilter() in src/reformat_libyuv.c:

#if LIBYUV_VERSION >= 1813
            if (I422ToARGBMatrixFilter(image->yuvPlanes[AVIF_CHAN_Y],
                                       image->yuvRowBytes[AVIF_CHAN_Y],
                                       image->yuvPlanes[AVIF_CHAN_U],
                                       image->yuvRowBytes[AVIF_CHAN_U],
                                       image->yuvPlanes[AVIF_CHAN_V],
                                       image->yuvRowBytes[AVIF_CHAN_V],
                                       rgb->pixels,
                                       rgb->rowBytes,
                                       matrixYUV,
                                       image->width,
                                       image->height,
                                       filter) != 0) {
                return AVIF_RESULT_REFORMAT_FAILED;
            }
#else

and

#if LIBYUV_VERSION >= 1813
            if (I422ToARGBMatrixFilter(image->yuvPlanes[AVIF_CHAN_Y],
                                       image->yuvRowBytes[AVIF_CHAN_Y],
                                       image->yuvPlanes[AVIF_CHAN_V],
                                       image->yuvRowBytes[AVIF_CHAN_V],
                                       image->yuvPlanes[AVIF_CHAN_U],
                                       image->yuvRowBytes[AVIF_CHAN_U],
                                       rgb->pixels,
                                       rgb->rowBytes,
                                       matrixYVU,
                                       image->width,
                                       image->height,
                                       filter) != 0) {
                return AVIF_RESULT_REFORMAT_FAILED;
            }
#else

The two I422ToARGBMatrixFilter calls are conditionally compiled only if LIBYUV_VERSION >= 1813.

I422ToARGBMatrixFilter was added to libyuv in this commit:

https://chromium.googlesource.com/libyuv/libyuv/+/ebb27d69160b3768187bb8372c01dcbf5e61785a

The LIBYUV_VERSION macro (defined in include/libyuv/version.h) has the value 1812 in that commit. Therefore, if LIBYUV_VERSION >= 1813, libyuv should have the I422ToARGBMatrixFilter function.

So the libyuv version test for the I422ToARGBMatrixFilter calls in libavif v0.10.1 is correct. I don't know why it doesn't seem to work in your environment. One possible explanation is that the /usr/lib/libavif.so.14 file on your machine was built on a machine with a newer libyuv (version >= 1813), but the libyuv shared library installed on your machine is an older version (< 1813). If that is what happened, then we need to specify that the libavif v0.10.1 package requires the same version of the libyuv package that it was built against.

[SpineEyE]

Yeah, seems to have been a mismatch with the libyuv version, it's fixed with a newer libyuv version: https://bugs.archlinux.org/task/74663

Thanks for your quick help.