Arch Linux User Repository

If the build fails:

• Clear your aur helper cache and SRCPKGDEST directory
• Rebuild in clean chroot 1
• If it still fails, use a paste bin 2 to show full build logs

There's a package build already which you can try out from my repo.

FAQ:

• The dependencies are correct. fmt and nlohmann_json are configured as subprojects for ease of development on my end, and it's only natural to statically link C++ projects, as ABI stability with exported C++ libraries isn't a thing (compared to C).
• If you think pod2man is missing, it's a configuration problem on your end. pod2man is part of the perl package, but in a perl-specific PATH handled by /etc/profile.d/perlbin.sh
• I'm only able to test auracle on i686 and x86_64, so that's what I'm willing to commit to in the PKGBUILD. If you want to build this on some other architecture, use makepkg -A. The "any" architecture is reserved for packages with architecture independent files (and compiled C++ is not).

@kozaki: the issue is that fmt is an automagic dependency (fifth paragraph), which means you will get different results whether or not fmt is installed. To avoid this, you can build in a clean chroot (not ideal but IMHO good practice).

The other solution is too disable dynamic linking by patching auracle's meson or something, but this has to be escalated to upstream, which has gone stale... (patches are welcome??)

@artafinde I use no AUR helper (beside auracle). The error I reported happened running makepkg manually on auracle-git PKGBUILD, with then without fmt installed. So I dunno what I'm missing.

TLDR: A rebuild in clean chroot will force fmt being statically linked.

a821: I didn't say I don't recognize or not acknowledge the issue. The reason this happened is fmt changed major version recently and so the libfmt.so.7 changed to libfmt.so.8 and "broke" auracle because the runtime dependency changed - makes perfect sense and expected - and users are expected to rebuild the AUR package. Now why would you remove fmt after you rebuild auracle, if you had it installed before, is beyond me and I can't understand it.

Upstream project is stale so I'm doing my best to keep the package working.

@artafinde: It seems that @xaad and @kozaki are correct; auracle will not download fmt if it is present in the system and it will be linked dynamically. I can easily reproduce it by compiling auracle in a clean chroot with fmt in it (see below). I guess a flag has to be passed to meson so it does not try to detect system fmt and forces its downloading (no idea how to do that though).

Here I'm building with fmt and base-devel. The configuration files are the ones extra-x86_64-build uses.

$ mkarchroot -C /usr/share/devtools/pacman-extra.conf -M /usr/share/devtools/makepkg-x86_64.conf /mnt/chroot/root base-devel fmt
...
$ makechrootpkg -r /mnt/chroot
...
Run-time dependency fmt found: YES 8.0.0
...
$ namcap auracle-git-r366.8739929-1-x86_64.pkg.tar.zst
auracle-git W: Referenced library 'libfmt.so.8' is an uninstalled dependency
auracle-git W: Dependency included and not needed ('libcurl.so')

Here you see fmt is found and it was not downloaded. The final package is linked to auracle as reported by namcap (you can check with ldd I guess). Compare building in a clean chroot with only base-devel

$ mkarchroot -C /usr/share/devtools/pacman-extra.conf -M /usr/share/devtools/makepkg-x86_64.conf /mnt/chroot/root base-devel 
...
$ makechrootpkg -r /mnt/chroot
...
Run-time dependency fmt found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency fmt
Downloading fmt source from https://github.com/fmtlib/fmt/archive/7.0.1.tar.gz
Downloading file of unknown size.
Downloading fmt patch from https://github.com/mesonbuild/fmt/releases/download/7.0.1-1/fmt.zip
Download size: 1238
Downloading: ..........

Executing subproject fmt

fmt| Project name: fmt
fmt| Project version: 7.0.1
fmt| C++ compiler for the host machine: c++ (gcc 11.1.0 "c++ (GCC) 11.1.0")
fmt| C++ linker for the host machine: c++ ld.bfd 2.36.1
fmt| Build targets in project: 1
fmt| Subproject fmt finished.

Dependency fmt from subproject subprojects/fmt-7.0.1 found: YES 7.0.1
...

$ namcap auracle-git-r366.8739929-1-x86_64.pkg.tar.zst
auracle-git W: Dependency included and not needed ('libcurl.so')

here fmt is downloaded automatically as expected and is linked statically (namcap does not report it)

Full logs with fmt: http://sprunge.us/UO2Jk6 Full logs without fmt: http://sprunge.us/NmjcO4

PS: I deleted the chroot dir between tries.

kozaki: I'm not sure what aur helper you might be using which does this described workflow, but fmt is not listed as dependency because auracle build tool will download it and statically link it (for reasons explained in pinned comment).

Continuing where xaap resolved his or her own issue:

1. Read pinned comment twice (may not be enough) ;)
2. Have fmt installed.
3. Build auracle-git and update it succesfully.
4. Run auracle clone [AUR_application]: error while loading shared libraries: libfmt.so.7: cannot open shared object file: No such file or directory.
5. Uninstall fmt (removing dependencies as reported by pacman).
6. Rebuilding auracle-git (does not pull fmt, only deps fakechroot, gtest & meson).
7. Same result as step 3.

L0ric0: Seems fine to me, remove your aur helper cache and rebuild. If problem persists paste your full makepkg logs (in a pastebin)

Xaap: seems like you resolved your issue.

the sha256sum for the abseil-fix.patch seems to be wrong

The dependencies are correct. fmt and nlohmann_json are configured as subprojects (...)

Well there's still some issue that I just run into:
1. Have fmt installed
2. Build auracle-git and install it
3. Uninstall fmt (no dependency break reported by pacman)
4. auracle is now broken
5. Rebuilding will eventually pull fmt as subproject and the issue goes away

Might still be some easy to fix case by simply requiring fmt as a depend?

@rekoil: Technically aarch64 is not on the supported arch list but if you want to compile it there the easiest way would be:

diff --git a/PKGBUILD b/PKGBUILD
index caec419..8d2851f 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -43,6 +43,7 @@ build() {

   # Some tests fail with these enabled
   CFLAGS=${CFLAGS/,-D_GLIBCXX_ASSERTIONS/}
+  CFLAGS=${CFLAGS/armv8-a/armv8-a+crypto}
   CXXFLAGS="${CFLAGS}"
   meson build "${meson_args[@]}"

The explanation is that the abseil subproject defines properly the march if it detects you are in ARM architecture but meson then adds the CXXFLAGS from makepkg.conf after whatever the projects definitions and that makes the march set back to the one from makepkg.conf. Visible here:

[..] -march=armv8-a+crypto -march=armv8-a [..]

-march=armv8-a+crypto : from abseil subproject

-march=armv8-a : from makepkg.conf