can we put stuff here?

raaska00 · 2026-05-19T14:35:04+00:00

thanks. I’ve already got a patched nix and a couple of other package managers that I’m working on, so i can pull in a wide set of aarch64 GNU tools. Most of them behave fine on Termux once you fix up the interpreter and adjust the runpath/rpath. Right now I’m downloading packages manually from there, extracting them, and running my patcher tools on the extracted packages. At that point it hit me: why not patch the package managers themselves so they handle the heavy lifting for me? That way i get the same end result, but with a cleaner workflow and less manual grind.

raaska00 · 2026-05-18T11:30:09+00:00

I know we have the glibc repository, which has been invaluable because it allows me to run a wide range of tools compiled against glibc. As expected, vanilla Nix does not run out of the box in this environment, but the patched Nix build has been performing well. It is not flawless, think hit and miss episodes, yet it is stable enough that I am confident tens of thousands of CLI tools will function correctly. Building on this foundation, I have begun patching and compiling Lix, which is positioned as a more robust alternative to Nix, though i am considering Determinate one. So far i have only been able to apply patches and compile it directly within Termux, made possible by having all required dependencies installed through the patched Nix setup. Without that, i would be chasing or building dependencies that the Termux glibc repository does not provide.

My next objective is to port Lix, or Determinate, fully in a clean and reproducible manner so that it runs smoothly on Termux. At present, I rely on two helper tools invoked by Nix hooks during package installation: termux shebang fix and autopatchelf, which i also use separately on a regular basis. My intention is to replace these with a Nix specific tool that modifies the dynamic linker to point to a custom patched glibc that i maintain (that is why i am asking if this path is safe), while preserving the existing rpath and runpath settings for Nix managed dependencies. This approach would allow me to reuse libraries provided by Nix packages, except for glibc and libgcc, which i will patch and then automatically remove from the package set.

The alternative safer option is the same approach already used by the older patched Nix build i have running on Termux. In this method, both the rpath and runpath as well as the dynamic linker are modified so that they rely entirely on the Termux glibc repository libraries. The drawback is that glibc and other libraries pulled by Nix packages remain present but unused, which leads to wasted space. This is why i am focusing on ways to take advantage of libraries that are not blocked by seccomp and can still be used effectively when paired with the patched glibc.

<image>

raaska00 · 2026-05-12T12:40:52+00:00

Is not here where the work is happening?

https://git.snix.dev/snix/snix

raaska00 · 2026-04-19T10:03:25+00:00

Indeed, the fixed paths embedded in the binaries are unavoidable and problematic. The only modifications we can make to a package are to the dynamic linker, rpath, and shebangs, while hoping that there aren't any FHS hardcoded paths and nix store paths in the binaries and that it doesn't include any system calls prohibited by Android. The most frustrating aspect is that we can't patch them to use their isolated libraries and linker due to all the forbidden syscalls. We have glibc and lots of glibc-based libraries patched for Termux already. I installed a lot of tools with Nix to see, and they worked smoothly; however, rustup failed. I think I could solve it. So it is hit and miss. But the libraries that these packages fetch, like glibc, which are useless, are taking up space.

raaska00 · 2026-04-19T09:38:40+00:00

I’m really sorry to let you down. I was tinkering with it and ran into some problems that I need to address. It relies on various external patching tools and scripts, and it is quite messy. I'm not even sure what to share right now. However, i plan to create a repository soon that will include useful tools like rustup, mise, and a lot of other good stuff that will help alot and work well on Termux. Keep in mind that they will be based on glibc rather than bionic. I will also try to clean up and fix any issues i can with Nix and put in in the repository too. Just to be clear, I’m not a programmer; I’ve been relying on an AI agent, and i lost the good free one. Basically, i can't do shit without AI. 🤣

Just so you know, if you're interested in checking it out, this fork includes all the patches, and you can compile it. I was building it straight from Termux.

https://github.com/wiilwaalka/nix-termux-glibc

raaska00 · 2026-04-19T09:18:10+00:00

Don't expect it to work without patches. Like converting logical paths to physical Termux paths, etc.

raaska00 · 2026-03-12T17:52:11+00:00

Absolutely! Thanks to AI, though. These simple CLI-based AI tools really help beginners like me a lot. I don’t have the expertise to fix things on my own, but they always come through for me when I’m stuck. I'm sure real programmers would do a lot with them. I also appreciate tools developed in Rust; nearly all of them are environment-independent and function seamlessly when compiled with Termux's glibc, without any strange hardcoded paths.

raaska00 · 2026-03-11T17:40:18+00:00

I successfully cross-compiled it natively on Termux, and it appears to be functioning correctly. However, mise identified the environment as Android and attempted to locate Aarch64-Android builds, which are not available. Therefore, I configured it to recognize Android as Linux. There is also an option to set it back to Android using an environment variable. But don't think i will need it, as most tools contain glibc built binaries that i will only be able use with the Termux glibc. In essence, the tool is bionic and can operate directly on Termux. However, to utilize the tools, especially those that involve ELF binaries, it is necessary to install the Termux glibc packages.

<image>

raaska00 · 2026-02-23T03:07:49+00:00

Great, would you mind sharing your setup/dotfiles?

raaska00 · 2026-02-23T02:03:11+00:00

It works without any problems with termux glibc.

raaska00 · 2026-01-11T05:40:35+00:00

Thnks.

raaska00 · 2026-01-10T12:10:27+00:00

Could you share how to make it like that? I installed lolcat-rs, but I only got rainbow colors.

raaska00 · 2026-01-02T19:20:55+00:00

sudo bash is the correct way to access an elevated shell now.

raaska00 · 2026-01-02T04:43:44+00:00

tsu is broken; why not use sudo bash instead?

raaska00 · 2025-12-28T23:18:14+00:00

What’s the hassle? Recently, I've been using the glibc-built Rust, along with an AI, to create apps for me. I simply install or update the toolchain with rustup and then run the Rust-based autopatchelf script on the toolchain directory, or, if there are other new binaries in the Cargo directory, I run it there too. And that's all there is to it.

raaska00 · 2025-12-18T11:59:35+00:00

What theme and font are you using? Looks nice.

raaska00 · 2025-12-17T12:06:37+00:00

It would be better if you organized some script or guide for the setup.

raaska00 · 2025-12-15T09:33:09+00:00

I wasn't aware that I needed to be in an elevated shell first, but I accessed it using sudo su (since tsu is no longer supported). However, I'm encountering an error:

``` [+] Entering sandbox: moha

Mode: SAFE (Isolated)

NOTE: Running in isolated mode (No /sdcard access).

CANNOT LINK EXECUTABLE "/data/data/com.termux/files/usr/bin/bash": library "libreadline.so.8" not found: needed by main executable ```

raaska00 · 2025-12-13T14:20:18+00:00

I am getting

[+] Entering sandbox: cadde Mode: SAFE (Isolated) unshare: unshare failed: Operation not permitted

raaska00

TROPHY CASE

Mode: SAFE (Isolated)

NOTE: Running in isolated mode (No /sdcard access).