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).

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

This does not build on aarch64 anymore.

[72/156] Compiling C++ object subprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p/absl_random_internal_randen_hwaes.cc.o
FAILED: subprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p/absl_random_internal_randen_hwaes.cc.o
c++ -Isubprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p -Isubprojects/abseil-cpp-20210324.1 -I../subprojects/abseil-cpp-20210324.1 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -std=c++17 -Wno-sign-compare -march=armv8-a+crypto -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fPIC -MD -MQ subprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p/absl_random_internal_randen_hwaes.cc.o -MF subprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p/absl_random_internal_randen_hwaes.cc.o.d -o subprojects/abseil-cpp-20210324.1/libabsl_random_lib.a.p/absl_random_internal_randen_hwaes.cc.o -c ../subprojects/abseil-cpp-20210324.1/absl/random/internal/randen_hwaes.cc
In file included from ../subprojects/abseil-cpp-20210324.1/absl/random/internal/randen_hwaes.cc:229:
/usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/include/arm_neon.h: In function ‘Vector128 {anonymous}::AesRound(const Vector128&, const Vector128&)’:
/usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/include/arm_neon.h:12321:1: error: inlining failed in call to ‘always_inline’ ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch
12321 | vaesmcq_u8 (uint8x16_t data)
      | ^~~~~~~~~~
../subprojects/abseil-cpp-20210324.1/absl/random/internal/randen_hwaes.cc:255:20: note: called from here
  255 |   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
      |          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../subprojects/abseil-cpp-20210324.1/absl/random/internal/randen_hwaes.cc:229:
/usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/include/arm_neon.h:12307:1: error: inlining failed in call to ‘always_inline’ ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
12307 | vaeseq_u8 (uint8x16_t data, uint8x16_t key)
      | ^~~~~~~~~
../subprojects/abseil-cpp-20210324.1/absl/random/internal/randen_hwaes.cc:255:20: note: called from here
  255 |   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
      |          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

tallero: read the pinned comment.

Add nlohmann-json, pod2man deps.

tallero: read the pinned comment.

can add architecture=any?

@haawda I tried today in the morning (~3h ago) and got the same checksum as you, but now it works again with checksum 'ca65cb7f...' github weirdness is going on...