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!

Worked fine up until recent cachyos update (within the past few days) the build fails with two errors:

nettle 4.0+ API change: repos/PureSpice/src/rsa.c line 65 calls sha1_digest(&ctx, SHA1_HASH_LEN, hash) but newer nettle removes the length parameter. Fix: sha1_digest(&ctx, hash)

GCC 16+ uninitialized variable warning: repos/nanosvg/src/nanosvg.h line 1656 declares float t[6] without initialization. Fix: float t[6] = {0}; Workaround: Apply these patches manually before building, or build from source outside of the AUR helper.

Still new to arch and AUR so had AI help with diagnosing this, but made changes to those two lines and looking glass launches just fine again.

getting looking-glass-client: error while loading shared libraries: libhogweed.so.6: cannot open shared object file: No such file or directory errors trying to run after the update to nettle 4.0.1 hoping for a fix soon,thanks!

@lborps Rebuild the package and install rebuild-detector

The client won't start

$ looking-glass-client
looking-glass-client: error while loading shared libraries: libsframe.so.2: cannot open shared object file: No such file or directory

$ yay -Qi looking-glass
Name            : looking-glass
Version         : 2:B7-5
Architecture    : x86_64
Depends On      : binutils  fontconfig  gcc-libs  glibc  gmp  hicolor-icon-theme  libegl  libgl  libpipewire  libpulse  libsamplerate  libx11  libxcursor  libxfixes  libxi libxinerama  libxkbcommon  libxpresent  libxss  nettle  wayland  zlib  zstd

$ yay -Ql binutils | rg libsframe
binutils /usr/lib/libsframe.a
binutils /usr/lib/libsframe.so
binutils /usr/lib/libsframe.so.3
binutils /usr/lib/libsframe.so.3.0.0

$ yay -Qi binutils
Name            : binutils
Version         : 2.46-1

@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