Adamcake
building for arm64 is a possibility?
Hello, I’m not very knowledgeable about C but I’d like to know if it’s possible to make this work. Would it require a lot of code changes? I travel a lot and have a poor internet connection, so I use an Android tablet with a Bluetooth keyboard and mouse as a desktop, running Termux-Proot with Debian. Everything works fine, and hardware acceleration is available in some hardware. With this setup, I managed to get 30-40 fps with Runelite on entry-level smartphone hardware, while also running other programs without issues. However, I couldn’t get Flatpak packages to work, and the AUR package is only available for x86, which isn’t compatible with my device.
The Java launcher works fine, but I only tested it on an old account that hasn’t been blocked by the Jagex launcher. I know there’s a mobile launcher, but it lacks important features like NPC aggression and a notification system, and Android kills the game client in the background every 2 minutes. It would be a great addition if the bolt launcher could run on arm64 android smartphones and tablets.
It's possible, yes. A couple of people have done this before apparently but
I don't have a device I can test it on for myself. You'll need to build
from source by reading the instructions in the readme, and make sure to use
BOLT_SKIP_LIBRARIES=1 to make it easier, but you shouldn't need any code
changes.
On Sat, 25 Jan 2025, 04:50 Rodolfo Souza, @.***> wrote:
Hello, I’m not very knowledgeable about C but I’d like to know if it’s possible to make this work. Would it require a lot of code changes? I travel a lot and have a poor internet connection, so I use an Android tablet with a Bluetooth keyboard and mouse as a desktop, running Termux-Proot with Debian. Everything works fine, and hardware acceleration is available in some hardware https://github.com/LinuxDroidMaster/Termux-Desktops/blob/main/Documentation/HardwareAcceleration.md. With this setup, I managed to get 30-40 fps with Runelite on entry-level smartphone hardware, while also running other programs without issues. However, I couldn’t get Flatpak packages to work, and the AUR package is only available for x86, which isn’t compatible with my device.
The Java launcher works fine, but I only tested it on an old account that hasn’t been blocked by the Jagex launcher. I know there’s a mobile launcher, but it lacks important features like NPC aggression and a notification system, and Android kills the game client in the background every 2 minutes. It would be a great addition if the bolt launcher could run on arm64 android smartphones and tablets.
Screenshot_20250125_013914_TermuxX11.jpg (view on web) https://github.com/user-attachments/assets/e0dfd434-77b4-44eb-98f1-d9824895b6c1 Screenshot_20250125_002820_TermuxX11.1.jpg (view on web) https://github.com/user-attachments/assets/dfd97344-c8b8-45f2-9762-952d2fa427b7 Screenshot_20250125_002453_TermuxX11.1.jpg (view on web) https://github.com/user-attachments/assets/d63a4558-9698-4011-a0c3-a254d0c5bcdc
— Reply to this email directly, view it on GitHub https://github.com/Adamcake/Bolt/issues/109, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHG6BIGAY6PYYYAXOO4BGAL2MMJYLAVCNFSM6AAAAABV265EZSVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAYTANZWGUZDAMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I was indeed able to compile for arm64 and practically didn't have to change anything; I just had an issue with CEF because it doesn't recognize the platform and keeps adding compilation flags like "-m64" and "-march=X86_X64" in the ./build/compile_commands.json file. There were no flags like -D CMAKE_C_FLAGS="-march=armv8-a", -D CMAKE_HOST_SYSTEM_PROCESSOR=arm64, or -D CMAKE_CXX_FLAGS="-march=armv8-a" that could solve the problem. So, I saved the compilation log and saw that the issue was in the file ./cef/dist/cmake/cef_variables.cmake, which has a conditional logic to check the platform that, for some reason, doesn't work. Thus, I manually edited the platform in the file.
From:
# Determine the platform.
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
set(OS_MAC 1)
set(OS_MACOSX 1) # For backwards compatibility.
set(OS_POSIX 1)
elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")
set(OS_LINUX 1)
set(OS_POSIX 1)
elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
set(OS_WINDOWS 1)
endif()
# Determine the project architecture.
if(NOT DEFINED PROJECT_ARCH)
if(("${CMAKE_HOST_SYSTEM_PROCESSOR}" STREQUAL "arm64") OR
("${CMAKE_CXX_COMPILER_ARCHITECTURE_ID}" STREQUAL "ARM64"))
set(PROJECT_ARCH "arm64")
elseif(CMAKE_SIZEOF_VOID_P MATCHES 8)
set(PROJECT_ARCH "x86_64")
else()
set(PROJECT_ARCH "x86")
endif()
endif()
To:
# Determine the platform.
set(OS_LINUX 1)
set(OS_POSIX 1)
# Determine the project architecture.
set(PROJECT_ARCH "arm64")
I used this version of the CEF arm64 binary, it was a version similar to what I had seen in the project github actions compilation script: cef_binary_126.0.1+g8abe66c+chromium-126.0.6478.17_linuxarm64_beta_minimal.tar.bz2.
Also had to compile the frontend because the compilation was failing at 93%. I believe there are two binaries, html_gen and icon_gen that were the cause. But it was very straightforward and had no errors, just following the steps described in the README. With the ninja flag, it's much faster to compile; even on the low-power device I have, it doesn't take more than a few minutes. On the other hand, regular CMake takes about 10 minutes.
For some reason, CMake isn't available in the apt package manager for the ARM64 version of Debian 12 Bookworm. However, the ARM64 .deb package is available on packages.debian.org . Only needed to install build-essential, npm, and the recommended dependencies listed in the README.
One caveat is that the Termux proot method doesn’t work well with Chromium's sandboxing mechanism, according to the internet. However, it works fine if you launch it with the --no-sandbox flag. For a staging build, the command is:
sh bolt.sh --no-sandbox. This problem happens with any app that uses the Chromium platform, like VSCode, which also needs to be launched with --no-sandbox.
Seems to be working fine! 😄
I'll keep testing more in the coming days, and I'll update here if anything weird comes up.
Interesting - thanks for the info.
html_gen and icon_gen are intermediary programs that output C++ code which is then compiled, and this is mainly a means of embedding files into the code as byte arrays. I can't really see why a different CPU architecture would cause issues there?
The issue with Chromium's sandbox is that it's based on a setuid binary, and a lot of systems will absolutely refuse to allow a setuid binary to be installed or to work correctly because of the major compromise in security that it represents. The org.chromium.Chromium guys patched it so that it'd be able to work in flatpak by making the sandbox use user namepsaces and unprivileged_userns_clone instead of setuid - maybe that would interest you. https://github.com/flathub/org.chromium.Chromium/blob/591fd8fe030e16de227b8cee1c86344ecb249ba9/patches/chromium/flatpak-Add-initial-sandbox-support.patch
In the flatpak package for Bolt, I've set it up to create an entire source build of Chromium and CEF within their build system. Since this process is entirely source-based, it should work on any architecture, in theory. The only issue/exception is the rust toolchain:
https://commondatastorage.googleapis.com/chromium-browser-clang/Linux_x64/rust-toolchain-31e6e8c6c5b6ce62656c922c7384d3376018c980-2-llvmorg-19-init-9433-g76ea5feb.tar.xz
Chromium downloads this file during the build, and there doesn't seem to be any aarch64 equivalent available for download. This is the only thing preventing the build from working on aarch64 at the moment, and is also the only case of having to download google's binaries, which I'd like to avoid for obvious reasons. But the only way to avoid this would be to work out how to recreate this file using Rust's build system.
Chromium has experimental build settings called use_chromium_rust_toolchain and rust_sysroot_absolute, which look like they're for the purpose of using a custom rust toolchain, so that's definitely worth looking into.
@rodhfr Do you think you would be able to make a step by step guide on how you did it, regarding compiling Bolt? What proot-distro did you use, what compilation flags did you use, etc. I would be interested to get it up and running, personally, and I guess it could be useful for others as well.
I could probably figure it out myself if I tried though, especially with the pointers you already wrote down here (thanks for that btw) so don't feel pressured, just thought that it could be useful to have it written down somewhere, to avoid repeating the effort.
@Baardi I can look into that next week. It was working fine last time I tried. Might automate the process if I have some time. Android Canary 2507 (probably android 16) released official linux VM native implementation that will run GUI apps with gpu accel. Thus probably being more useful for the general public. Yet would take some time to be better than the hacky termux solution apparently.