Arch Linux User Repository

If you encounter any issues building a package from this PKGBUILD and/or running the resulting binaries:

DO NOT CONTACT UPSTREAM!!!

This PKGBUILD is not supported nor provided by upstream!

Only leave messages here on the AUR!

@zhou13; you should not be hitting anything in that sub-dir unless you're modifying the PKGBUILD. As per 2025-09-10 the build of the host component was also removed from the PKGBUILD (the packaging was already removed per 2025-10-20 but I realized I forgot the build itself when I back-ported a patch for the client).
Just use the latest version of the PKGBUILD and this should not affect you.

If you are re-adding the host component, there is not much I can do for you; looking at the information you've provided, it's clear that you're /NOT/ building with the Arch Linux provided defaults.
The flags even suggest you might potentially not even be on an Arch Linux system at all?? The flags seems to suggest potentially some ARM distro/system.

I personally still use and check the host component locally but as before; it's impossible to reproduce this on any Arch Linux system I have build it with; bare metal installs, dockerized and clean chroots.
If you are building packages I would highly advice doing so in a clean chroot, at minimum if you encounter any issues, so you can eliminate problems caused by personal customizations; https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
This is of course assuming you're on an Arch system in the first place.

I am using

CARCH=$(uname -m | sed 's/7l/7h/')
#CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=native -O3 -pipe"
CXXFLAGS="-march=native -O3 -pipe"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j"$(nproc --all)
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

and

❯ g++ --version
g++ (GCC) 15.2.1 20251112

Which I don't think it is different. I can still reproduce this problem.

@zhou13: that is indeed one way to deal with it. I've checked if anything changed due to a build tooling update or something that would've caused this to start triggering recently but I can't reproduce it. Are you by chance running a makepkg config that deviates from the Arch Linux defaults?

Modify the prepare stage PKGBUILD to

    sed -i '1 i\#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"' \
        "host/platform/Linux/capture/pipewire/src/portal.c" \
        "repos/nanosvg/src/nanosvg.h"

fixes the problem

In file included from /home/yichaozhou/.cache/yay/looking-glass/src/looking-glass-B7/repos/nanosvg/src/nanosvgrast.h:28,
                 from /home/yichaozhou/.cache/yay/looking-glass/src/looking-glass-B7/client/src/overlay_utils.c:32:
/home/yichaozhou/.cache/yay/looking-glass/src/looking-glass-B7/repos/nanosvg/src/nanosvg.h: In function ‘nsvg__parseTransform’:
/home/yichaozhou/.cache/yay/looking-glass/src/looking-glass-B7/repos/nanosvg/src/nanosvg.h:1656:15: error: ‘t[0]’ may be used uninitialized [-Werror=maybe-uninitialized]
 1656 |         float t[6];
      |               ^
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
make[2]: *** [CMakeFiles/looking-glass-client.dir/build.make:268: CMakeFiles/looking-glass-client.dir/src/overlay_utils.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:583: CMakeFiles/looking-glass-client.dir/all] Error 2

missing simde as makedepends

@Omar007 would be nice to apply the patch of https://github.com/gnif/LookingGlass/pull/1197 in order to fix the FSR & CA filters on current mesa versions

unfortnuately the AUTHORS patch fails to apply

Ended up having time to make the CI changes today so as of now, the AUR mirror of this PKGBUILD has the host component disabled.

some top shelf drama. for the record i think Omar007 has managed this package well

Ok so the previous questions and actual state never mattered. Thank you for clarifying that.
That means it's just a political decision as it is not currently broken (I actively used it today!). That is fine by me but please just say so immediately next time. I'm more than willing and inclined to fix things, which is why I didn't just bail and drop it at the first sign of an issue. Though in this case it is not about fixing anything, I'll also do my best to accomodate.

As such, I'll rework my tooling so it will be removed from this PKGBUILD when it is mirrored to the AUR by the end of next week then (best case thursday at the earliest).