Very, very confused about properly sourcing libsignal-client JAR during native build process

[slithernix]

I've followed all the threads about this, and I've also got a native build working some time ago by just copying a dylib into the lib structures when I did the build on my mac. I can't for the life of me figure out, if I am building the native image, where do I source or build the JAR for libsignal-client that is referenced all over? i see it in the release tarball, but how does it even get there?

when you run the build_jni script in libsignal (as directed in the wiki article about building your own lib) you just get the shared object. All the instructions in the various threads discussing this then say to delete the .so from the JAR, then replace it with your custom built one. As if the JAR just exists...

So I looked for the JAR in the repo, would be weird for it to be checked in but who knows. Unsurprisingly, it wasn't there. So then I thought, maybe the only thing inside this JAR is for some reason this shared object, so i downloaded the release tarball, looked at jar tvf and that told me indeed there is actually compiled java too. So, where on earth do I actually get/build this JAR file? If the answer is 'get it from the release tarball' i'm still just as confused because how does it get there?

Furthermore, it looks like you still need to copy this into the java libs on the target system, which is exactly what I was hoping to avoid with a native image build, assuming it would be static minus its glibc linking...

[slithernix]

nevermind- found the JAR, was looking a directory too deep. it's at java/client/build/libs/libsignal-client-0.36.1.jar

[m-ueberall]

Furthermore, it looks like you still need to copy this into the java libs on the target system, which is exactly what I was hoping to avoid with a native image build, assuming it would be static minus its glibc linking...

Just to clarify: If you're referring to a native binary (built using GraalVM), then you do not need to deploy the system-specific dynamic libsignal_jni library–the latter is included/embedded in the binary and will be extracted/loaded at run-time.

[slithernix]

the strange thing is, i'm building this native binary with graal in a dockerfile using debian 11.8 as the FROM (my target platform is debian 11.8). my workstation itself is running Ubuntu 22.04 and when i run the resultant native binary on the workstation it runs fine and does not spit out the error about libsignal_jni.so and libsignal-client.

It is the target system on Debian 11.8 that spits out that error. I didn't think it was possible to be more lost than I already was, but now I am officially lost in space.

[slithernix]

i guess i need to do what you're saying in #1333, which i have been trying to do and hitting various snags. gonna go heads down on this for a couple hours and see what i can come up with.

[slithernix]

alright boom, your instructions on 1333 which I had already taken into account but thought were failing- were actually pretty on the money. the problem was that I had specified a bad path at one point in the Dockerfile which was wreaking havoc on the build and I kept overlooking it which led me down a rabbit hole.

one note, i think on the recommendation to sed s/android for the gradle settings, you really want to use /android/d, which removes that whole android line.

thanks a lot for your comments on these posts they helped me out a lot!!

[m-ueberall]

thanks a lot for your comments on these posts they helped me out a lot!!

Glad to know these helped! One thing to keep in mind: Debian 11.8 uses glibc 2.31 whereas Ubuntu 22.04 uses glibc 2.35, which means that at some point you might end up with a binary/embedded dynamic library that does not work anymore on your target platform (if both are build from scratch in your build environment). In that case, you'll need to switch to Ubuntu 20.04 and make sure to have a newer protobuf-compiler package in place (see issue #1245).

EDIT: This will definitely become a lingering problem from libsignal_jni.so version 0.39.2 onwards (haven't checked earlier versions as we specifically use a modified Ubuntu 20.04/Focal build environment for this purpose) as can be seen here:

# sdiff ./libsignal_jni_so0392_ubuntu2004_amd64.buildinfo ./libsignal_jni_so0392_ubuntu2204_amd64.buildinfo
LIBSIGNAL=v0.39.2                                               LIBSIGNAL=v0.39.2
LIBSIGNAL_GITREV=5436160313d4fa43ea225918138866d05f2da6f7       LIBSIGNAL_GITREV=5436160313d4fa43ea225918138866d05f2da6f7
LLVM=v1:17.0.6-4~ubuntu20.04+projektzentrisch.de+1            | LLVM=v1:17.0.6-4~ubuntu22.04+projektzentrisch.de+1
CARGO="v1.77.0-nightly (2ce45605d 2024-01-04)"                  CARGO="v1.77.0-nightly (2ce45605d 2024-01-04)"
BINUTILS=v2.42-2ubuntu1~ubuntu20.04+projektzentrisch.de+1     | BINUTILS=v2.42-2ubuntu1~ubuntu22.04+projektzentrisch.de+1
GCC=v13.2.0-13ubuntu1~ubuntu20.04+projektzentrisch.de+1       | GCC=v13.2.0-13ubuntu1~ubuntu22.04+projektzentrisch.de+1
MIN_GLIBC=v2.29                                               | MIN_GLIBC=v2.34

The minimal glibc version in the last line is basically derived from the below:

objdump -T "target/${CARGO_BUILD_TARGET}/release/libsignal_jni.${LIBSUFFIX}" >"${WORKDIR}/${LIBSIGNALFILE}.objdump"
MINGLIBCVER="$(grep GLIBC "${WORKDIR}/${LIBSIGNALFILE}.objdump" | grep -vE '_2\.[0-9]\.|_2\.[0-9])' | sed -e 's|.* (|(|g' | sort | tail -1)"

[slithernix]

good info here- I generally build using docker with the FROM line matching the target platform to avoid these kind of sly mismatches that can really ruin your day.