ARM64 native binary compliation conundrum #1230
Replies: 24 comments 19 replies
-
|
I tried to compile the native version on my Raspi400 with 64bit Bulls Eye and the Java17 version of graalvm. |
Beta Was this translation helpful? Give feedback.
-
@julianfairfax : Seeing the answer by @bublath earlier today, I retraced your steps in an Ubuntu 20.04 LXD build container (using 'GraalVM 22.3.1 Java 19 CE', '19.0.2+7-jvmci-22.3-b12', gcc (linux, aarch64, 9.4.0)) on an OCI Ampere A1 Compute instance (4 OCPUs, 24GB of RAM). Compilation took 3.5 minutes (on tmpfs I then moved these files out of the way and reran the previous command with So unless the (successful) reduction of the number of workers also affects the required amount of RAM, the only option would be to use a more powerful build machine. If you're lucky and the free offer linked above is still available, this might be your best bet (…until someone forks the project and attaches an ARM64-based GitHub runner to automatically produce binaries for each upstream release or the like). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Markus for trying. That confirms my suspicion that actually every retry (needed 3) brought me closer to the target and it was just a coincidence that using the max-workers=1 in the last attempt seemed to help, as the native build in gradle seemed to use only one worker anyways. |
Beta Was this translation helpful? Give feedback.
-
IMHO, as long as you see the below, it should be compatible (given that the PinePhone uses an Allwinner A64 ARM Quad core Cortex-A53), though it might require an additional Another question would be whether it's required to produce a statically linked binary (depending on the Linux distribution in use which @julianfairfax didn't mention), because the dynamically linked one (here: built on Ubuntu 20.04/Focal) requires the following: |
Beta Was this translation helpful? Give feedback.
-
|
After 4 attempts, over an hour of execution, I still haven't been able to build the binary with |
Beta Was this translation helpful? Give feedback.
-
|
I wonder why I did not see this. Probably even the native build process includes the libsignal-client jar file that is provided in the standard package which is for am64. I'm not sure how to replace this in the build process, but maybe you can place the library somewhere in your LD_LIBRARY_PATH (e.g. /usr/lib) - I have a matching one here: |
Beta Was this translation helpful? Give feedback.
-
Placing that file in /usr/lib doesn't work. |
Beta Was this translation helpful? Give feedback.
-
|
You're right. As soon as I try more than printing the version, I'm getting the same issue and can't make it use the correct native library. |
Beta Was this translation helpful? Give feedback.
-
This might have something to do with it? #713 (comment)? https://github.com/AsamK/signal-cli/wiki/Provide-native-lib-for-libsignal? "with a recent enough version of glibc, see #643" |
Beta Was this translation helpful? Give feedback.
-
|
Exactly - that is how I created the library quoted above. The problem is that with the executable, I can't replace the shared library and also cannot set something like |
Beta Was this translation helpful? Give feedback.
-
|
libsignal-client is a transitive dependency of signal-cli, but you can exclude it and add your libsignal-client-0.22.0.jar file, by adding the following to the main build.gradle.kts file: dependencies {
implementation(files("/path/to/libsignal-client.jar"))
}
configurations.all {
exclude(group = "org.signal", module = "libsignal-client")
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot. |
Beta Was this translation helpful? Give feedback.
-
It works! I'm not sure if this really well and truly solves the issue though, since I still can't build it on my device, and presumably can't build it on a Pi 3, nor setup GitHub actions or GitLab CIs to build it for me. |
Beta Was this translation helpful? Give feedback.
-
|
Cool that this helped. Since the RAM requirements for the build are exceeding that of a Pi3 or your other device by far, i don't think there is an alternative to cross compiling this on a stronger machine. There are probably ways to properly configure the build scripts to create aarch64 even on a PC (or GitHub servers), but I'm no expert in that. |
Beta Was this translation helpful? Give feedback.
-
Are there? |
Beta Was this translation helpful? Give feedback.
-
|
@julianfairfax : You can, e.g., use pbuilder in conjunction with QEMU and binfmt magic to create a chrooted build environment for a number of architectures nowadays. I currently use this to experiment with a Seeing that the native |
Beta Was this translation helpful? Give feedback.
-
|
@m-ueberall: I just did a "strip" command on libsignal_jni.so and it went from 19MB to 2.7MB. I never thought about checking for symbols before. Could explain the difference. |
Beta Was this translation helpful? Give feedback.
-
Do you think that would be possible to run in a GitHub action/GitLab CI?
That binary works for me. If you keep uploading it, I'll keep using it. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Maybe. 😁 For this to work, you'd either need provided runners that support nested virtualization (or run on bare metal) or use your own. Until recently, neither of those choices would work for GitHub in conjunction with public projects and a free plan. There have been some developments in this respect, but I have yet to see a success story/try it myself (see this long-running discussion). In any case, I'd suggest to set up a “simple” chroot or virtual machine using QEMU on a (somewhat beefy) local Linux machine first. If GraalVM works in that environment, it should be possible to (slowly) come up with a runner configuration suitable for one of the prominent CD/CI tools. Also, the initial setup can always be used as a fallback. Trying to set up everything at once from scratch sounds … “rather challenging”. [*] read: I'm still working on completing a self-hosted, heterogenous build cluster myself; parts work, others don't, and it's quite time-consuming/challenging. |
Beta Was this translation helpful? Give feedback.
-
|
I can close this an mark it as solved, but if you (@AsamK) could move it to a discussion, it would be better. |
Beta Was this translation helpful? Give feedback.
-
@m-ueberall I'm using your binary to build an arm64 Debian package for signal-cli: https://gitlab.com/julianfairfax/package-repo/-/blob/main/signal-cli/build_deb.sh. Please let me know if this is an issue for you, and I'll remove it. |
Beta Was this translation helpful? Give feedback.
-
Not at all! 😄 |
Beta Was this translation helpful? Give feedback.
-
Would you maybe be able to describe in a little more detail how to do that? I'm using Arch on a laptop with an AMD Ryzen 7 4800H and 16GB of RAM, if that's a beefy enough machine. If possible, I would like to go the chroot route, as I know how to use chroots, and it would probably be easy to maintain. Essentially, how do I setup that arm64 chroot environment, within which I will simply compile signal-cli with the commands mentioned in the OP? |
Beta Was this translation helpful? Give feedback.
-
|
@AsamK you have more experience with this tool. Do you have any idea what could be the problem? Refer to #1230 (reply in thread) for all the commands I've run |
Beta Was this translation helpful? Give feedback.
-
|
@m-ueberall should I give up with the chroot and try some other type of environment? Like whatever you used here #1230 (reply in thread)? |
Beta Was this translation helpful? Give feedback.
-
While LXD is available on Arch, the problem in this case is that it's currently not possible to use it in order to create virtual machines or containers that use a different architecture: In theory, thanks to nested virtualization, it could be possible to install LXD within an arm64/aarch64 VM, but I've never tried this. (And in case of problems, it can be very difficult to locate the cause.) Of course, if it works, it works. OTOH, given that I can attest for sure that the same script to build (*) you want also make sure that nothing related to GraalVM/JVM/JDK is installed from a different source than the one(s) specified above (to avoid the risk that there's an overlooked configuration file somewhere) |
Beta Was this translation helpful? Give feedback.
-
How would I do that? Can I create an arm64 Debian chroot on am64 Arch? |
Beta Was this translation helpful? Give feedback.
-
Yes you can, as long as you follow, e.g., this short description (substitute “bullseye”, “debian-arm64” for “xenial”, “ubuntu-arm64” in the example, respectively). You need to install the required dependencies using something along the lines of EDIT: With a current |
Beta Was this translation helpful? Give feedback.
-
|
Found the solution to building signal-cli from an amd64 system (in this case, an Arch one): https://gitlab.com/julianfairfax/package-repo/-/blob/main/signal-cli/prebuilt.sh A prebuilt is now available at https://gitlab.com/julianfairfax/package-repo/-/blob/main/signal-cli/prebuilt/signal-cli (direct download). Thank you for all your help! Full log if anyone's interested: (I'm unsubscribing from this. Mention me if you need me.) |
Beta Was this translation helpful? Give feedback.
-
|
Actually, @AsamK is there any chance you could link to my binary in https://github.com/AsamK/signal-cli#installation, or perhaps even add it to the regular releases? I plan on building each new version of yours as a native ARM binary within a day or two of the new version's release. |
Beta Was this translation helpful? Give feedback.
-
|
You could add a link to it too the wiki |
Beta Was this translation helpful? Give feedback.
-
I'm trying to compile the native binary for ARM64, by using a PinePhone. I followed the instructions from https://github.com/AsamK/signal-cli/blob/master/README.md#user-content-building-a-native-binary-with-graalvm-experimental, and ran the following commands:
The problem is, compilation never completes. I think the longest I was able to get it to run for was 45 minutes, at which point it was still not done compiling, still at 90%, which it stays at forever after passing the 5-10 minute mark. Usually however, it doesn't even get to 45 minutes, freezing before then.
No matter how many times I've tried it, I have never been able to get signal-cli to compile with the native binary. And, the standard binary suffers from the performance issues described in https://github.com/AsamK/signal-cli/wiki/FAQ#performance, especially on low-powered devices like the PinePhone.
Any solution to this would be welcome.
Beta Was this translation helpful? Give feedback.
All reactions