https://aur.archlinux.org/pkgbase/libjpeg-xl-git
seems our makepkg (or something related) behaves a little differently than standard arch..
specifically, in the case of this PKGBUILD, standard arch doesn't require this option: 
-DCMAKE_INSTALL_LIBDIR:PATH='/usr/lib'
whereas on obarun, without that option, libs get installed in $pkg/usr/lib64, causing a failure..
lrwxrwxrwx 1 root root 3 Oct 30 12:52 /usr/lib64 -> lib/
lrwxrwxrwx 1 root root 7 Oct 30 12:52 /lib -> usr/lib/
So anything going to /usr/lib64 end up in /usr/lib, unless you have removed the links intentionally. Otherwise there is no difference from arch. Alternatively you can use the .configure on the pkg to direct the libraries to /usr/lib

But I see the comment section is full of your debate with the Klingons that run arch public relations. They feed off heretics not doing things their way or using pkgs outside their control. From one side they consider AUR as not part of arch, but on the other hand they CONTROL AUR as being solely for the use of Arch. Meanwhile they have 3-4-5 year old unmaintained versions of runit and openrc on AUR, but anyone trying to use anything but systemd is NOT arch.

So why bother even talking to those bozos?

I use yaourt, and in all the years I use to makepkg PKGBUILDs and then pacman -U ***.xz has never had a different outcome of yaourt. ARCHers hate yaourt. They now hate trizzen too, but that huge blob of crap they call yay is now a good thing. Still it is not arch officially.

The PKGBUILD is messed up, nothing wrong with trizzen or your obarun.
There are three files that seem to be trying to be removed twice by the script while building. 
rm: cannot remove '../pkg/libjpeg-xl-git/usr/lib/libhwy.a': No such file or directory
rm: cannot remove '../pkg/libjpeg-xl-git/usr/lib/pkgconfig/libhwy.pc': No such file or directory
rm: cannot remove '.../pkg/libjpeg-xl-git/usr/lib/pkgconfig/libhwy-test.pc'
Even creating (touch) those three files and restarting makepkg it still gave the same error, which means it removed them and then it tried removing them again. So it has nothing to do with arch/obarun or trizzen, but the pkg itself being messed up. I give up because I don't need it and it is huge.
ah well, "those bozos" could be anyone.
to be clear, once the extra cmake option is added, the package builds and works fine.
i am just curious as to :
1. why the source/cmake appears to default to /usr/lib64 when usually(in a distro that still uses lib$ARCH eg. slackware) /usr/lib64 needs to be specified..
and
2. what difference there might be between 'straight' arch and obarun that would make that cmake option superfluous.. ie. some weirdarse systemd shitfuckery that's crept into makepkg.. and that obarun maintains it's own pacman suggests this might be the case..
I don't understand this at all, if it is a cmake configuration issue it would have to do with a different cmake in arch and obarun, but cmake 3.19.2-1 comes from extra, it has nothing to do with obarun. So where is the configuration that results in a correct build in arch but fails in obarun and needs this configuration you added?

Maybe Eric and JM know the answer to this one. The errors I got were exactly the same using yaourt or makepkg and had to to with the removal of those 3 files. The reason it seems this happens is because the pkg is building from lib64
-rw-r--r-- 1 xxx users  56K Dec 30 03:02 pkg/libjpeg-xl-git/usr/lib64/libhwy.a
-rw-r--r-- 1 xxx users  15K Dec 30 03:05 pkg/libjpeg-xl-git/usr/lib64/libjxl_threads.a
-rw-r--r-- 1 xxx users 6.4M Dec 30 03:09 pkg/libjpeg-xl-git/usr/lib64/libjxl.a
-rwxr-xr-x 1 xxx users  19K Dec 30 03:10 pkg/libjpeg-xl-git/usr/lib64/libjxl_threads.so.0.2.0*
-rwxr-xr-x 1 xxx users 3.9M Dec 30 03:11 pkg/libjpeg-xl-git/usr/lib64/libjxl.so.0.2.0*
lrwxrwxrwx 1 xxx users   23 Dec 30 03:30 pkg/libjpeg-xl-git/usr/lib64/libjxl_threads.so.0 -> libjxl_threads.so.0.2.0*
lrwxrwxrwx 1 xxx users   19 Dec 30 03:30 pkg/libjpeg-xl-git/usr/lib64/libjxl_threads.so -> libjxl_threads.so.0*
lrwxrwxrwx 1 xxx users   15 Dec 30 03:30 pkg/libjpeg-xl-git/usr/lib64/libjxl.so.0 -> libjxl.so.0.2.0*
lrwxrwxrwx 1 xxx users   11 Dec 30 03:30 pkg/libjpeg-xl-git/usr/lib64/libjxl.so -> libjxl.so.0*
But how does arch pass this configuration to cmake and we have to do it manually?
couple of more (strange) things:
the gdk-pixbuff and gimp plugin bits install correctly to $pkg/usr/lib/ without the explicit cmake lib option ..
... the jxl.cmake file appears to reference ${CMAKE_INSTALL_LIBDIR} ..not sure where that is set (apart from as an option and internally in the source somewhere)

from archwiki cmake package guidelines itself:
https://wiki.archlinux.org/index.php/CMake_package_guidelines# Prefix_and_library_install_directories
Some upstream projects set their CMake files to install libraries into the /usr/lib64 directory. If this is the case, you can correctly set the library installation directory to /usr/lib by using the -DCMAKE_INSTALL_LIBDIR=lib CMake option.
and an example of this in an official arch PKGBUILD:
https://github.com/archlinux/svntogit-packages/blob/packages/brotli/trunk/PKGBUILD
doesn't necessarily mean anything: documentation and packaging are not always up with the latest..

i also compared our pacman with standard arch, and couldn't see anything relevent there.. the only difference in the makepkg.conf regarding zstd packaging
> i also compared our pacman with standard arch, and couldn't see anything relevent there.. the only difference in the makepkg.conf regarding zstd packaging

Yes, and pacman.conf having obarun repositories added, more restricitve in verifying pkgs, preventing systemd and libs to ever install, etc.
Makepgs could just be a separate pkg really, it is not even dependent on pacman. It is just an automated way to build a pkg out of a PKGBUILD file, compress the outcome and save into a file that you can install with pacman.
you will not found difference between pacman from Arch and pacman from Obarun (for the moment). I provide pacman on Obarun repo only to control the come of new version(by the past, a new versionned pacman package has broken the installer due of the zstd format).
You will not found difference between makepkg from Arch and makepkg from Obarun except the fact that the declaration of the source inside the PKGBUILD file accept a field with ssh:// as address.
So, you can use any PKGBUILD from Arch on a Obarun system. That not means that a package that come from Arch will build correctly under Obarun cause of e.g. dependencies.
Anyway, as you noticed (https://wiki.archlinux.org/index.php/CM … irectories) you need to precise the $pkg/usr/lib/ directory at CMAKE_INSTALL_LIBDIR if the upstream use /usr/lib64 by default. Under Arch /usr/lib64 is a symlink and it's not "recognize correctly" at installation time, so the package try to make the /usr/lib64 directory which already exist. As contrary if the upstream use by default /usr/lib even for the lib64 library you don't need to specify the CMAKE_INSTALL_LIBDIR.
To make a short answer, this depends of the upstream policies choice and this is not depends of the pacman/makepkg program.

Powered by Obarun