Request: provide a static PIE ARM64 server build for Android/Termux compatibility

[tychushu]

Hi VoceChat team,

I am running VoceChat Server 0.5.33 ARM64 on a Samsung Galaxy S24 Ultra using Termux.

Currently it works inside:

Termux
└── proot-distro Debian
    └── VoceChat Server 0.5.33 ARM64

I would like to migrate the server from the Debian/proot environment to native Termux.

This is not only for reducing overhead or simplifying deployment. I have encountered intermittent stability problems with long-running services under proot, which is the main reason I am trying to move these services to native Termux.

Why I want to migrate away from proot

My current Debian environment uses:

proot-distro
proot 5.1.0 (Termux fork)
seccomp acceleration enabled

Several unrelated long-running applications have occasionally failed with ENOSYS (Function not implemented) errors after running for hours.

Examples I have observed include:

VoceChat Server

VoceChat, using Rust/Tokio, has occasionally terminated with an epoll/polling-related error similar to:

unexpected error when polling the I/O driver

with the underlying syscall returning:

ENOSYS

Beszel Hub

The Go-based Beszel Hub has occasionally received:

futex(...) = -1 ENOSYS

followed by a Go runtime failure such as:

morestack on g0

Beszel Agent

I have also observed operations involving:

pipe
fork

occasionally failing with:

Function not implemented

These failures are intermittent rather than immediately reproducible.

I performed short stress tests comparing:

native Termux
proot + seccomp enabled
proot + seccomp disabled

and was not able to reproduce the failure during approximately 30-second tests.

However, disabling proot's seccomp acceleration caused syscall-heavy workloads to become roughly an order of magnitude slower in my testing, so simply disabling seccomp is not an attractive solution for long-running services.

The exact race or compatibility issue has not been conclusively identified, but the common characteristic is that otherwise valid basic Linux syscalls occasionally return ENOSYS inside the proot environment after extended runtime.

In comparison, services running directly under native Termux have been much more stable in my setup.

For example:

• native Termux Syncthing has not exhibited this issue;
• I have successfully built Beszel Hub / Agent from the official source for native Termux, and it now runs without the proot layer.

Therefore my preferred long-term architecture is:

Android
└── Termux native
    ├── Syncthing
    ├── Beszel
    └── VoceChat

instead of:

Android
└── Termux
    └── proot Debian
        ├── Beszel
        └── VoceChat

VoceChat is currently the main remaining service that I cannot migrate because the current official ARM64 server binary cannot be loaded natively by Android/Termux.

---

Binary information

The VoceChat binary was extracted from the official ARM64 Docker image.

file ./vocechat-server

Output:

ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped

ELF header:

readelf -h ./vocechat-server | grep Type

Output:

Type: EXEC (Executable file)

Additional checks:

readelf -d ./vocechat-server
readelf -l ./vocechat-server | grep INTERP

show that the binary has:

- no DT_NEEDED dependencies
- no PT_INTERP
- static linking

The .comment information indicates that the binary was built using approximately:

rustc 1.98.0
aarch64-unknown-linux-musl

Problem on native Termux / Android

When Termux attempts to launch the binary through Android's linker64, it is rejected before VoceChat application code starts:

unexpected e_type: 2

e_type = 2 corresponds to:

ET_EXEC

For comparison, normal Termux executables such as:

$PREFIX/bin/bash

are built as:

ET_DYN

and are accepted by the Android loader.

Therefore this particular failure happens at ELF loading time and is unrelated to VoceChat configuration, data files, TLS certificates, networking, HOME, TMPDIR, or the server database.

---

Experiments

For testing only, I copied the binary into an isolated directory and experimented with converting the ELF from ET_EXEC to ET_DYN.

I tried:

1. changing e_type from ET_EXEC to ET_DYN;
2. rebasing the ELF entry point and load-segment virtual addresses;
3. constructing a minimal PT_DYNAMIC;
4. constructing a .dynamic section.

This allowed Android's linker to progress further, but the resulting executable was not a valid real PIE binary.

This is expected because changing ELF metadata after compilation cannot safely transform code originally linked as a fixed-address executable into genuinely position-independent code.

The production VoceChat binary and production data were never modified.

---

Request

Would it be possible to provide an additional ARM64 static PIE build of VoceChat Server?

Ideally:

Architecture: AArch64
libc: musl
Linking: static
ELF type: ET_DYN / PIE
External shared-library dependencies: none

For example:

readelf -h vocechat-server | grep Type

should return something similar to:

Type: DYN (Position-Independent Executable file)

instead of:

Type: EXEC (Executable file)

I am not requesting official Android or Termux support, nor any Android-specific changes to VoceChat.

If the existing ARM64 build pipeline could publish an additional correctly linked static PIE AArch64 artifact, I would be happy to test it on my S24 Ultra and report whether the server runs correctly under native Termux.

Even an experimental build artifact would be very useful.

Why this may be useful beyond my setup

A static PIE ARM64 binary could make VoceChat easier to deploy in lightweight ARM64 environments where Docker or a complete Linux userspace is undesirable.

In my particular case, native execution also avoids an additional syscall translation layer that has caused intermittent problems for multiple long-running services.

VoceChat 0.5.33 already works correctly for me under Debian/proot, so this is not blocking normal use.

The request is specifically about obtaining a cleaner and more reliable long-term deployment:

Android → Termux → VoceChat

rather than:

Android → Termux → proot → Debian → VoceChat

Thank you for maintaining VoceChat.

I would be happy to test any experimental ARM64 static-PIE build and provide readelf, runtime logs, or other diagnostic information if needed.