Arch Linux User Repository

For me, it fails with java-21-openjdk as well. But with a slightly different error:

> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65

(notice 65 instead of 66)

For me, it compiles correctly with java-17-openjdk. Also, I don't think you need to uninstall other version, once you switch with archlinux-java set.

I was able to work around the new build failures by installing JDK 21 explicitly and removing the generic JDK package that is currently pointing to JDK 22. I expect it's using a newer bytecode version that isn't supported by build tools being used.

pacman -S jdk21-openjdk
archlinux-java set java-21-openjdk
pacman -Rsn jdk-openjdk

Build fails for me:

==> Making package: libsignal-client 0.39.2-1 (Fri 29 Mar 2024 13:30:31 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found libsignal-0.39.2.tar.gz
==> Validating source files with sha512sums...
    libsignal-0.39.2.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting libsignal-0.39.2.tar.gz with bsdtar
==> Starting prepare()...
==> Sources are ready.
==> Making package: libsignal-client 0.39.2-1 (Fri 29 Mar 2024 13:30:41 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
cargo build --frozen -p libsignal-jni --release
[...]
    Finished release [optimized + debuginfo] target(s) in 15m 33s
mkdir -p java/shared/resources
cp target/release/libsignal_jni.so java/shared/resources/

Welcome to Gradle 7.6.4!

Here are the highlights of this release:
 - Added support for Java 19.
 - Introduced `--rerun` flag for individual task rerun.
 - Improved dependency block for test suites to be strongly typed.
 - Added a pluggable system for Java toolchains provisioning.

For more details see https://docs.gradle.org/7.6.4/release-notes.html

To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.6.4/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

FAILURE: Build failed with an exception.

* What went wrong:
Could not open cp_settings generic class cache for settings file '/home/arch/.cache/yay/libsignal-client/src/libsignal-0.39.2/java/settings.gradle' (/home/arch/.cache/yay/libsignal-client/src/.gradle/caches/7.6.4/scripts/c5uid1ri8esi9ij0j7q87vc39).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 66

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 6s
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: libsignal-client-exit status 4

Could you please provide the libsignal-client-bin and signal-cli-bin versions? My supercomputer takes ages to compile them...

Yep thanks for the info. Here's my PKBGUILD for the C ABI called libsignal_ffi that the go version of mautrix-signal uses: https://aur.archlinux.org/packages/libsignal-ffi

Yes, this is just the java part (jar and jni so file). It would probably be best if you provide a separate package, I mainly maintain this package for signal-cli, which also requires a specific libsignal-client version.

Hi @AsamK,

Just a quick message as I maintain the mautrix-signal PKGBUILD, and the switch from a signald-based to a go-based build has just happened with release 0.5.0. It now uses libsignal under the hood. Am I right in my observation that this libsignal-client is in fact just the java aspect of libsignal? In the installation process of mautrix-signal, it expects libsignal_ffi.a which, unless I've missed something, is not provided by this PKGBUILD.

I've started trying to get libsignal to build with the terse cargo build instructions from the libsignal README, but I have some boringssl errors... Still working on those.

Would you consider rewriting this PKGBUILD so it actually provides the rust component of libsignal? Or would you prefer me to keep that separate in another PKGBUILD (if I can get the thing to build that is...), something like libsignal-client-rust maybe?

Thanks for your input, Regards, Mark.

PS: I know there is a binary release, mautrix-signal-bin, I'm interesting in an Arch Linux-built binary though.

@dreieck add -x javadoc to the gradle cmd in the PKGBUILD, fixed it for me.

@dreieck jdk17-openjdk seems, as you suggest, not to be needed, thank you

I can also build version 0.31.0 with the PKGBUILD from here and java-environment or just jdk-openjdk in makedepends.

So if anyone else need version 0.31.0 without being forced to use jdk17-openjdk, it can be done with this:

In PKGBUILD change: pkgver=0.31.0

makedepends=('cargo' 'gradle' 'git' 'zip' 'protobuf' 'cmake' 'clang' 'jdk-openjdk')

sha512sums=('a066ab3e654b4b9b31acd8fb603d8ad148f05c79f5003a3246311186b3169db699a7d4ca7925170de49eafa2768863243f69f0af46853e0435a235e06737dcac')

save and run makepkg --install

A note on Java version:

I successfully built (version 0.31.0-git) with just having java-environment as make dependency and having this fulfilled by currently most up to date jdk-openjdk version 20.0.2.u9-3.

So maybe jdk17-openjdk is not specifically needed, and java-environment might be a good make dependency instead.
But you could add versioned dependencies if needed, e.g. java-environment>=17 or/ and java-environment<29.

Regards and thanks for maintaining!