Implementing QEMU about termuxarch

[JanuszChmiel]

I had a big dream. Run Wine for X86 on Aarch64 platform and run my favourite audio games for visually impaired by using Linux on Android device by using Proot. Unfortunately, The most .exe apps have been compiled for X86 or for X64. There is no free simple converter, which could simply convert machine code from one platform to another. Play those games on A phone instead of a standard IBM/PC compatible machine would be very exciting idea. BUt I know, that Qemu would be very probably too slow to allow this. The next important question is, if build Wine pulseaudio sound support would be compatible with used approach, that TCP protocol is being used to stream sound packets to Pulseaudio server which run in Termux not on a real Linux distro such as Arch Linux. But it would be very interesting experiment.

[JanuszChmiel]

I love one really unique audio games for visually impaired. Its name is topspeed. It is written by using Visual C++. It uses 3d sound to simulate real car race. You can hear cars around you, when you want to run fater than The car infront of you, you can hear The sound of The slower car. User must turn right, left, Cars can run to various ways. The source on Github is here. https://github.com/PlayingintheDark/TopSpeed But I must warn you that simply recoding this complex C source to be compatible with Linux compiler will not be easily possible. I love also other game, which is compiled by using special game engine for audio games development. It require X86 environment and Wine emulator. Topspeed also require WIndows emulator. I AM afraid, that Wine will not support to use Topspeed, since it uses many dlls from Microsoft corporation which is copyright problem. Microsoft directX to generate sound, and Microsoft Visual C++ redistributable. Here is other excellent audio game for us. It is Tube simulator from London. http://www.ndadamson.com/get-tubesim-portable.php

[JanuszChmiel]

Oh. And will be possible to run some X86 apps while working with AARch64 CPU? It would be excellent.

[JanuszChmiel]

I have never tried Unicon before. I have tried Alpine term which contain preconfigured Qemu. Alpine term have ooted whole Linux kernel and other sub systems. Speed is very slow. But if somebody would use expensive very fast mobile phones, it would not be so bad. I have also tried bochs or similar Android apps based on Qemu. The positive aspect of emulated environment based on The Termux and Alpineterm package is The 100% accessible environment so visually impaired user can monitor even kernel messages while system is being booted. Bash shell and other text based apps are also producing accessible text output. So Android screen readers can work with this operating system. If you will try to use Unicon please try to add some script which will download .iso automatically and user will have The chance to try it and test more effectively. Since copying data from one folder to other and manually making some changes to only try some bootable iso is limiting factor for testers. I also know, that it is not correct to compare emulator with Proot. Proot is being working at other principles than Qemu or other modules based on it. Qemu emulate CPU hardware, Proot uses special routines to monitor system calls and those routines are reacting on many situations. But C code uses CPu and RAM and Proot do not emulate CPU like Qemu. Proot also contain some special source code file which monitor CPu registers. It si complex C app. But I must confirm, that its speed will be always The fastest possible. Since not rooted devices can not use Kqemu Qemu accelaration Qemu kernel module. The advantage of Qemu booted distros is, that it is regular Linux, all Linux possible wotking kernel modules will work. This is not possible when using Proot. Since Proot do not emulate CPU it do not emulate computer PCI and other hardware system resources.

[ShapeShifter499]

Does this still work? it's hanging at Downloading from http://mirror.rackspace.com... This may take a long time pending connection

trying to bash setupTermuxArch.sh qemu and selecting option 5 for x86_64

EDIT: Also seeing this, might want to update the script.

Package qemu-user-x86_64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  qemu-user-x86-64

[JanuszChmiel]

Mr Rausty,

I would like to warn you for very important Qemu issue. It is speed of The executed code. Because Android devices can not be rooted simply. As A result, normal user have no chance to patch his used Android kernel with Kqemu kernel module. Because to be honet, Qemu which execute complex code is only usable if it is accelerated with Kqemu kernel module. As A result, Fedora support wonderful virt-manager which uses Qemu in conjunction with Kqemu. There is even An attempt to allow users of Termux to boot whole Linux distro no in userspace mode as Proot technique allows.
https://github.com/xeffyr/alpine-term

It is even possible to run various Linux distros by using this technique. But The execution speed is very slow even on Octa core CPUS with ANdroid 8.0 and with 4 GB of RAM.

Proot still offer The best execution speed when comparing with Qemu which do not use Kqemu kernel module for its accelerated running. Kqemu requires hardware virtualisation to be available on A ARM CPU. The question is, if cheap ARM cpus even contain hardware virtualisation when CPU is being manufactured in The factory.

I have tried Alpine with Termux which run by using Qemu. It runs, but because Qemu emulates CPu hardware, it cost many penalties.

Yours idea is goodly thinked, but speed wwill be very probably The limitation factor.

[JanuszChmiel]

Yes I fully agree with you in this point of wiev. The next true is that if Qemu is being used not to boot whole Linux distro with whole kernel, that there is not too much instructions to execute and Qemu can be good alternative.

[SDRausty]

regarding the data set:

Option setupTermuxArch o displays part of the data set at present. May I get a little help with naming the option name for this new feature please?

This short piece of code literally tapped itself into place before my eyes earlier in the afternoon today:

printf "\e[1;32m%s \e[0m" "$(tr -d '\n' < $0)"
# split the string
IFS=';' read -ra my_array <<< "$(tr -d '\n' < $0)"
# print the split string
for EMSTRING in "${my_array[@]}" ; do printf "\e[0;32m%s" "$EMSTRING" && sleep 0.0"$(shuf -i 0-999 -n 1)" ; done

This short piece of code literally tapped itself into place before my eyes in what seemed like a few short minutes as I was, you could say, mussing. I was taking a break from thinking about how to resolve this QEMU one tap automation topic, and tapping my smartphone screen while meditating about this issue.

This is much too much code to leave for amusement in the setup file. It should migrate to one of the axillary files, and soon will be moved. File espritfunctions.bash seems like a valid recipient for the Matrix enhancement function where it will have some room to develop like this newly forked TermuxArch repository did 7 years ago:

Just a bash script; duplicates the effect of the matrix in a terminal; uses katakana Japanese characters

This presentation can be a good entry point for the future coder who might be code phobic today. What option should this presentation receive? The present option setupTermuxArch o[ption] can be expanded into a full data set presentation in Matrix format in the cli screen:

@JanuszChmiel thank you for coming up with a very nice name for the Orca project we are working on for long months now. The name orcaconfig that you suggested today is a good name for what the user wants to do.

Name suggestions for the TermuxArch Matrix option are requested. When free time is found please share your thoughs here. The o option should remain open for future development.

The matrix option can be accessed with this setupTermuxArch mat[rix] command.

[SDRausty]

If your target install system is aarch64/arm64 then this line of code CPUABI="$(getprop ro.product.cpu.abi)" should be changed to CPUABI="arm64-v8a".

Lines 596 through 600 in file setupTermuxArch have more information about how to manually choose the correct architecture for this Planned implementation of the QEMU automatation which is still currently an absent option:

# Used for development; The command 'getprop ro.product.cpu.abi' can be used to ascertain the device architecture. Matching an alternate CPUABI* will install an alternate architecture on device. The original device architecture must be changed to something else so it does not match. This is usefull with QEMU to install alternate architectures on device.

declare CPUABI5="armeabi"	# Used for development;  The command 'getprop ro.product.cpu.abi' can be used to ascertain the device architecture.  Matching an alternate CPUABI* will install an alternate architecture on device.  The original device architecture must be changed to something else so it does not match.  This is usefull with QEMU to install alternate architectures on device.
declare CPUABI7="armeabi-v7a"	# used for development
declare CPUABI8="arm64-v8a"	# used for development
declare CPUABIX86="x86"		# used for development
declare CPUABIX86_64="x86_64"	# used for development

[SDRausty]

$ f ro.product.cpu.abi setupTermuxArch

634:CPUABI="$(getprop ro.product.cpu.abi)" && SYSVER="$(getprop ro.build.version.release)" && NASVER="$(getprop net.bt.name ) $SYSVER" || _PSGI1ESTRING_ "CPUABI setupTermuxArch ${0##*/}"

Change $(getprop ro.product.cpu.abi) to one of the five architectures that are mentioned above to install this architecture.

[SDRausty]

Simply by opening this topic the goal is much closer, and should be easier to obtain. Do you agree?

speed will be very probably the limitation factor.

I cannot but agree from what I know of the subject of QEMU. However there is even a bitter bigger limiting factor than the one we are dwelling on here right now! This is being able to install an alternate architecture in a smartphone easily with one tap only! Do you agree with this point of view dear Mr @JanuszChmiel?

[SDRausty]

run my favourite audio games for visually impaired

Can you share with us please what these games are? And are they available at GitHub?

[SDRausty]

This 7eb1440#diff-147d3dac5c5d3cacbd74a5925f7ef3cfR522 commit adds basic QEMU support for TermuxArch. To access this new future you can use this command setupTermuxArch q[emu] [customdir]. The command setupTermuxArch h[elp] provides help information.

This command still does not support installing QEMU which must be installed manually. If installing x86_64 on a 64-bit arm smartphone, this is a recommended QEMU package configuration:

qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]

$ pkg list-a|f qemu                                               
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.  
936:qemu-common/stable 1:4.2.1 aarch64                                           
937:qemu-system-aarch64-headless/stable 1:4.2.1 aarch64
938:qemu-system-arm-headless/stable 1:4.2.1 aarch64                              
939:qemu-system-i386-headless/stable 1:4.2.1 aarch64
940:qemu-system-riscv32-headless/stable 1:4.2.1 aarch64
941:qemu-system-riscv64-headless/stable 1:4.2.1 aarch64
942:qemu-system-x86_64-headless/stable 1:4.2.1 aarch64
943:qemu-user-aarch64/stable 1:4.2.1 aarch64
944:qemu-user-arm/stable 1:4.2.1 aarch64
945:qemu-user-i386/stable 1:4.2.1 aarch64                                        
946:qemu-user-riscv32/stable 1:4.2.1 aarch64                                     
947:qemu-user-riscv64/stable 1:4.2.1 aarch64                                     
948:qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]                      
949:qemu-utils/stable 1:4.2.1 aarch64

A proot qemu bind should also be created. File /var/binds/fbindexample.prs has information how dynamically create proot binds in TermuxArch.

[SDRausty]

To use this new feature which is currently being developed:
1) Install qemu for the target architecture,
2) Choose option setupTermuxArch q[emu] [customdir],
3) Create a qemu bind in directory /var/binds/.
File /var/binds/fbindexample.prs has more information...

[SDRausty]

It would be excellent.

It appears that this issue is down to three simpler steps now. This is still a long way away from a one tap any architecture chosen install if possible. The install steps are outlined here;

1. Install qemu for the target architecture,
2. Choose option setupTermuxArch q[emu] [customdir],

3. Create a qemu bind in directory /var/binds/. File /var/binds/fbindexample.prs has more information...

I am glad to see that this issue has made a little headway.

[SDRausty]

possible to run some X86 apps while working with aarch64

This error /usr/bin/env: Invalid ELF image for this architecture happens on aarch64 when x86 is chosen:

Setting mode to qemu.  This feature is being developed.
Please install one of the qemu tools from this list in a new session if not already installed before continuing:
qemu-user-aarch64/stable 1:4.2.1 aarch64
qemu-user-arm/stable 1:4.2.1 aarch64
qemu-user-i386/stable,now 1:4.2.1 aarch64 [installed]
qemu-user-riscv32/stable 1:4.2.1 aarch64
qemu-user-riscv64/stable 1:4.2.1 aarch64
qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]
Please select the architecture by number from this list:
1) armeabi
2) armeabi-v7a
3) arm64-v8a
4) x86
5) x86_64

[SDRausty]

possible to run some X86 apps while working with aarch64

It appears like it is possible to achieve this goal since this 77751cb commit. The command ./setupTermuxArch qemu install i386 will attempt to install and configure an x86 installation in an ~/i386 alternate directory after choosing option 4) x86 @JanuszChmiel. There are still a few rough edges in the configuration sections which deserve honing.

[SDRausty]

speed will be very probably The limitation factor.

Speed can be benchmarked with this script. The current limiting factor is the different configurations which the different architectures have @JanuszChmiel. Have you had any success with alternate architectures on your smartphone?

Notes about reinstalling for testing, this command setupTermuxArch i customdir can be called to assist in the task of testing the install process:

[i[nstall] [customdir]] Install Arch Linux in a custom directory. Instructions: Install in userspace. The HOME directory is appended to the installation directory. To install Arch Linux in HOME/customdir use 'bash setupTermuxArch install customdir'. In the BASH shell you can use './setupTermuxArch install customdir'. All options can be abbreviated to one, two and three letters. Hence './setupTermuxArch install customdir' can be run as 'setupTermuxArch i customdir' in BASH.

The newly implemented command setupTermuxArch q i customdir can also be summond to help resolve this issue:

[q[emu] [customdir]] Partial Implementation: Install alternate architecture on smartphone with QEMU.

The command setupTermuxArch h has more information. If space is not an issue on smartphone it may be possible to run all the possible architectures for testing this issue.

[SDRausty]

This c1b1e83 commit automates installing the user selected QEMU component and closes this issue. Should there be individual architecture issues regarding this QEMU implementation, please open a new issue specifying the architectures used, and the exact nature of the issue.

[SDRausty]

run some x86 apps while working with aarch64 CPU?

@JanuszChmiel the mirrorlist and specific instructions for installing x86 are at this archlinux32 link. These are the available Arch Linux architectures on an aarch64 smartphone:

[12:00~]$ uname -m
aarch64
[12:00~]$ startarch+armeabi-v7a c uname -m
armv7l
[12:00~]$ startarch+x86_64 c uname -m
x86_64
[12:01~]$ startarch+x86 c uname -m
i686
[12:01~]$ startarch c uname -m
aarch64

[SDRausty]

@JanuszChmiel there are upstream difficulties with https://bbs.archlinux32.org/viewtopic.php?pid=7409 on smartphone:

newer root file systems are unavailable for download

newer isos available here: https://archive.archlinux32.org/iso/

Alas an iso is not a rootfs and cannot be used to install Arch Linux without a CD/DVS drive.

EDIT: Alas an iso is not a rootfs and cannot be used to install Arch Linux without a mounted drive.

[SDRausty]

Update from https://bbs.archlinux32.org/viewtopic.php?pid=7447:

Maybe someone with the bandwidth, expertise, hardware and time will step forward and resolve this matter of rootfs publication for Arch Linux 32. One of the questions that I have is: Can the root file system be incorporated into Arch Linux 32 https://archive.archlinux32.org/iso/ like it was in 2017 for Arch Linux https://archive.archlinux.org/iso/2017.03.01? If so how?

Where's the source code to Arch Linux 32 iso creation and publication? This information should help this topic immensely.

[SDRausty]

This commit eeada6b updates the status of Arch Linux 32 in arm architecture.

[SDRausty]

Where's the source code to Arch Linux 32 iso creation and publication?

abaumann
replied https://bbs.archlinux32.org/viewtopic.php?pid=7448#p7448

Last time I checked there where Vargrant scripts in https://git.archlinux32.org/releng/
and https://git.archlinux32.org/archiso32/.

[SDRausty]

newer root file systems are unavailable for download

newer isos available here: https://archive.archlinux32.org/iso/

levi replied https://bbs.archlinux32.org/viewtopic.php?pid=7439#p7439

If you want to do the work to enable it then sure. Otherwise we're really just a hobbyist project, and the filesystem is there, we leave it up to you to pack it up as you want to.

Does anyone have a dusty old computer box with peripherals stored away that can be revived to run Arch Linux 32 without emulation to create a publishable root file system?

[SDRausty]

This commit 03e5ed9 automated qemu refresh; setupTermuxArch qemu refresh.

[SDRausty]

This commit 0d5c115 updates contact information for Arch Linux x86 and x86_64 distributions and also updates the Arch Linux x86 mirrorlist.

[SDRausty]

Reprint from bbs.archlinux32.org:

I have updated the automation of the Arch Linux 32 qemu installation for Android today; The mirror list and resolve config improvements install the system in two taps on modern smartphones. It appears that the root file system published back in 2017 is updatable:
Total Download Size: 116.71 MiB Total Installed Size: 455.75 MiB Net Upgrade Size: 124.48 MiB

The errors mentioned at the beginning of this issue still linger and prevent the Arch Linux 32 system from updating properly. Output when trying to install the sudo package:
error: sudo: signature from "Erich Eckner (just to sign arch packages) <[email protected]>" is unknown trust :: File /var/cache/pacman/pkg/sudo-1.9.3.p1-1.0-i686.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occurred, no packages were upgraded.

What is the simplest way to resolve this error without creating and publishing an updated root file system?

[SDRausty]

It appears that installing the key, and then this http://archive.archlinux32.org/packages/p/pacman/pacman-5.2.1-1.4-i686.pkg.tar.xz package can move this issue forward with configuration automaton for x86 emulation without an updated and published Arch Linux 32 root file system.

The topic of Arch Linux 32 configuration is being actively discussed here.

[SDRausty]

A solution is found! @wmcb-tech confirmed and wrote:

@SDRausty this is the setup process that i gone through and works fine as intended:

There are more details here and here.

[SDRausty]

One of the testharnesses used in attempting to resolve this issue for emulated x86 computer architecture in Android is presented here:

setupTermuxArch p
mkdir ~/arch ; cp ~/archlinux-bootstrap-2017.03.01-i686.tar.gz ~/arch/
setupTermuxArch q

File knownconfigurations.bash and this issue, "Error while Configuring Arch x86_64 on arm SDRausty/TermuxArch#259" have notes about testing this configuration and installation script on Android smartphone:

KEEP=1 ## change to 0 to keep downloaded image; Testing the installation process repeatedly can be made easier and lighter on your Internet bandwith and SAR with 'KEEP=0' and this fragment of code 'mkdir ~/arch; cp ~/ArchLinux*.tar.gz* ~/arch/' and similar. The variable KEEP when changed to 0 (true) will keep the downloaded image and md5 files instead of deleting them for later reuse if desired. The root file system image and md5 files can be saved and used again on subsequent installs when testing the install feature with this and similar fragments of code.

[SDRausty]

Levi wrote:

will finally become the only real use for this old project [Arch Linux 32]

Minimum space required to install the installation on device (Android smartphone) can also be a strong motivator here:

1. aarch64 1500MB
2. arm7 1250MB
3. x86_64 800MB

The minimum install size for Arch Linux 32 appears to be around 400 megabytes.

[SDRausty]

This commit 892c432 currently customizes for Arch Linux 32 with this code:
X86INT="whoami ; curl -OL http://archive.archlinux32.org/packages/p/pacman/pacman-5.2.1-1.4-i686.pkg.tar.xz ; pacman -U pacman-5.2.1-1.4-i686.pkg.tar.xz ; rm -f pacman-5.2.1-1.4-i686.pkg.tar.xz ; gpg --keyserver keyserver.ubuntu.com --recv-keys 0x194e37a47a4c671807bacb37b1117bc1094ea6e9 ; whoami"

[SDRausty]

The Arch Linux 32 system now installs and configures as expected with this commit. This issue is now fully resolved as all five architectures of Arch Linux (armv5, armv7, aarch64, x86_64 and x86) install and configure as expected in Android.

Note: The TermuxArch command orcaconf designed to assist visually impaired users of Arch Linux also appears to work correctly in Arch Linux 32. Issue, "Expanding setupTermuxArch so visually impaired users can install Orca screen reader (assistive technology) and have VNC support added easily. #34" has more information about this topic.

[SDRausty]

it would be very interesting experiment.

The very interesting experiment is now active as this issue is closed. Please participate and share your thoughts. At present these emulation options are present; setupTermuxArch qemu and setupTermuxArch unicorn:
./setupTermuxArch h|f emulation

[q[emu] [refresh] [customdir]] Install alternate architecture on smartphone with https://github.com/qemu/QEMU emulation. Issue [Implementing QEMU #25](https://github.com/TermuxArch/TermuxArch/issues/25) has more information.

[u[nicorn] [refresh] [customdir]] Partial Implementation: Install alternate architecture on smartphone with https://github.com/unicorn-engine/Unicorn emulation. This option currently defaults to option qemu as it is a partial implementation. Issue [Implementing QEMU #25](https://github.com/TermuxArch/TermuxArch/issues/25) has more information.

[SDRausty]

What is your impression of QEMU emulation in Android?

I would like to add one more emulator; It is called Unicon. Have you tried Unicon emulation in your smartphone?

Originally posted by @SDRausty in #34 (comment)

[SDRausty]

I have never tried Unicorn before.

Neither have I managed to get Unicorn working like QEMU. When this issue was opened I knew QEMU should work as expected; Then I had read about Unicorn CPU architecture emulation.

Currently, I would like to know how to use Unicorn emulation. This will make it easier to implement Unicorn emulation into setupTermuxArch and TermuxArch itself.

[SDRausty]

As option setupTermuxArch qemu option 4) x86 appears to have difficulty functioning as expected, this issue is reopened again. Testing is requested.

Note: Please note when testing on a standalone smartphone, please backup your work before continuing with testing.

[SDRausty]

Quote from bbs.archlinux32.org:

Even if stability with the approach that we have taken now is reachieved (updating the ancient 2017 root file system, as opposed to publishing a current rootfs along with the published Arch Linux 32 isos the Arch Linux 32 project graces us with), I believe publishing an updated rootfs is the most stable approach to resolving this topic.

[JanuszChmiel]

I have typed ./setupTermuxArch.2 qemu Installer have downloaded very probably normal file system with Archlinux which is being directly executed by Proot. How can I try real Qemu emulation? Or my impressio is wrong and if I will use qemu option and option 4 in The prompt screen, system will really download file system which will be executed by Qemu? Not only by using Proot without qemu?

[SDRausty]

How can I try real Qemu emulation?

You are using real QEMU emulation @JanuszChmiel; You can check with the pkg list-installed | grep qemu command in vanilla Termux.

[JanuszChmiel]

Because setupTermuxarch.bash q Allow Me only to choose The architecture so I choose 4 number. But I Am see error that au or similar command not found. So is it really possible to try I386 ArchLLinux with qemu? Or I must be patient since it is not possible for now and everything must e patiently developed to achieve this goal?

[SDRausty]

It appears that all of the Arch Linux versions once more install and configure with this a5672d4 commit, including Arch Linux 32. After running setupTermuxarch qemu you can choose option 4) x86 to access thr Arch Linux 32 distribution.

Please share how the update went @JanuszChmiel. It appears that the TermuxArch command orcaconf works Arch Linux 32 too.

[SDRausty]

Arch Linux 32

Work notes about updating the Arch Linux 32 configuration in TermuxArch are at docsTermuxArch. The update sequence was initially expanded. Then it was reduced to the seven steps currently used. These changes got the Arch Linux 32 automatic update to run successfully once more in TermuxArch on smartphone.

[SDRausty]

Unicorn working like QEMU

Active Closed 20201112 discussion thread at https://www.reddit.com/r/termux/comments/jsa4b6/ive_successfully_installed_unicorn/ and addition was debated:

QEMU is a complete emulator ready for use.

Unicorn is a CPU emulator engine, a library providing a APIs for running binary code on emulated CPUs. Start with https://www.unicorn-engine.org/docs/tutorial.html if you are interested in this.

[SDRausty]

Please see proot info: vpid 1: terminated with signal 11 #141 regarding why this issue is reopened.

This error continues only to occur on armv7l architecture; aarch64 qemu-user-i386 and qemu-user-x86_64 architecture packages work as expected.

[github-actions]

Stale issue message

[SDRausty]

run my favourite audio games for visually impaired

I would like to share the latest 'audio games' milestone with you here in this issue @JanuszChmiel:

user05:20~$ yay ghcup-hs
1 aur/ghcup-hs-bin 0.1.17.4-3 (+10 0.04)
an installer for the general purpose language Haskell

---

GHCup-hs works flawlessly in TermuxArch; THANK YOU! Did you know that Haskell can play music from code? Tap here to see video search results.

output.mp4

Link to this sample of Haskell music source code.

Can anybody else who uses Termux please try it? I would like to hear your opinion about the way Haskell makes music from code in Termux please.

Originally posted by @SDRausty in termux/termux-packages#8758 (comment)

[JanuszChmiel]

I have spent some time to found AN reliable and possible way to run X86 Windows apps. It is possible thanks to https://github.com/ptitSeb/box86 But project must be run under Linux distribution which is ARM32 Bit, not AArch64 Bit one. And unfortunately, Termux do not allow users to choose which architecture user would want to use. It simply automatically download bootstrap files according To the automatically detected CPU architecture. It is not A problem if user do not want to run box86. Next problém is, that it is necessary to obtain X86 Windows prefix, Wine Windows files which mmust be X86. So my dream would be too complex to reach for now.

[SDRausty]

I would like to hear your opinion about the way Haskell makes music from code in Termux please.

[SDRausty]

under Linux distribution which is ARM32 Bit, not AArch64

I am checking the availability of box86 in Arch Linux 32 with the option that we have developed here in this issue; Have you tried box86 in Arch Linux32?

[SDRausty]

too complex to reach for now

availability of box86 in Arch Linux

Arch Linux aarch64 yay box86 result:

user08:08~$ yay box86
2 aur/box86 0.2.4-2 (+2 0.01)
    Linux Userspace x86 Emulator with a twist
1 aur/box86-git v0.2.4.r22.g4813a35e-1 (+3 0.01)
    Linux Userspace x86 Emulator with a twist

QEMU Arch Linux system emulation might not be neccessary to run box86 on our Android smartphones.

[JanuszChmiel]

Yes I will try it but I must remove older Termux and I must upgrade to 118 version. I had issues with makeyay script and I did not set user password for janusz so I could not use Sudo which makeyay script call. So I must reinstall Whole Termux and ArchLinux but I will 100 % try yay ghcup-hs command and I will try Haskel and its play sound feature. I believe, that it will support Pulseaudio for Termux.

[SDRausty]

did not set user password

Since Termux is a one app and one user environment with the same permission scheme, does it make any sense to use passwords once a Termux session is opened?

[SDRausty]

Can anybody else who uses Termux please try it?

Yes I will try it

I have made an new issue Run my favourite audio games for visually impaired #68 for in depth discussion regarding creating music with Haskell in TermuxArch.

If you have difficulty installing box86 in TermuxArch, please open a new issue or comment in #68 as this one is already very very long.

[SDRausty]

# two AUR ghcup packages