[v0.13.6] native build: libsignal changed to `libsignal_jni_amd64.so`

[morph027]

https://github.com/AsamK/signal-cli/blob/v0.13.6/graalvm-config-dir/resource-config.json#L188 changed the search pattern to libsignal_jni_amd64.so for at least amd64 builds which results in not found error when bundling as libsignal_jni.so.

I've updated my build script accordingly: https://gitlab.com/packaging/signal-cli/-/commit/638c3f235dbfabc9e637e66b80f536d9bd854ba3

Might be interesting for @m-ueberall .

Should we update https://github.com/AsamK/signal-cli/wiki/Provide-native-lib-for-libsignal for the changes too?

If so, do we want to change the naming for arm64 also?

[m-ueberall]

.@morph027: I'll have a look at the build logs tonight, but at first sight, it looks like L188 got added and L186 is still referencing a libsignal_jni.so. Likewise, there's a .dylib entry (L184), so I guess whichever library is found will be used (not sure about the order in which they would be processed, but only one should be available anyway)?

[morph027]

Build log is good, but i'm running tests afterwards against sandbox servers.

SLF4J(I): Connected with provider of type [ch.qos.logback.classic.spi.LogbackServiceProvider]
2024-09-09T12:52:06.147Z [main] DEBUG org.asamk.signal.util.IOUtils - XDG_RUNTIME_DIR not set, falling back to temp dir
2024-09-09T12:52:06.147Z [main] DEBUG org.asamk.signal.App - Starting signal-cli 0.13.6
2024-09-09T12:52:06.232Z [main] WARN  org.asamk.signal.manager.Manager - Failed to call libsignal-client: Can't load library: /tmp/libsignal4964863784128629644/libsignal_jni_amd64.so
Missing required native library dependency: libsignal-client

[AsamK]

The logic for loading the native library is implemented here in libsignal-client: https://github.com/signalapp/libsignal/blob/main/java/shared/java/org/signal/libsignal/internal/Native.java#L70

It first tries to load a library with an architecture suffix (_amd64) and then tries without the suffix. The file extension depends on the OS (.so, .dylib, .dll)

[morph027]

Hm. The one without suffix exists in the old version of the build script, but it wasn't working.

[m-ueberall]

Strange. The local build script always uses libsignal_jni.so, and I have not seen the above warning in the syslog during an initial quick test on amd64 and arm64 hosts. @morph027: Is your build in question still available on https://gitlab.com/packaging/signal-cli/-/artifacts?

[morph027]

Nope, unfortunately i deleted the build after i kind of "fixed" it with a new commit.

The log output above is from a local build which is using the same steps as the CI. I will spin up a build again and attach the artifact, if you like to test or have a look.

[morph027]

You can find the resulting binary here: https://download.morph027.de/signal-cli_issue_1582.tgz

[m-ueberall]

@morph027: Got it, thanks!

[exquo]

Out of curiosity, what are the testing files in the .jar?

❯  unzip -l signal-cli-0.13.7/lib/libsignal-client-0.58.0.jar
…
11897312  1980-02-01 00:00   libsignal_jni_aarch64.dylib
12473504  1980-02-01 00:00   libsignal_jni_amd64.dylib
70163000  1980-02-01 00:00   libsignal_jni_amd64.so
 3240824  1980-02-01 00:00   libsignal_jni_testing_aarch64.dylib
 3294928  1980-02-01 00:00   libsignal_jni_testing_amd64.dylib
22230392  1980-02-01 00:00   libsignal_jni_testing_amd64.so
11090432  1980-02-01 00:00   signal_jni_amd64.dll
 4204544  1980-02-01 00:00   signal_jni_testing_amd64.dll
…

[AsamK]

Those have some additional testing APIs, they're not used by signal-cli. https://github.com/signalapp/libsignal?tab=readme-ov-file#maven-central

[exquo]

Thank you!