Package Request: .NET Core

[christianrondeau]

This project is a very promising initiative to develop in .Net with real cross platform support.

Website: https://www.microsoft.com/net/core (already supports multiple Linux distros)

And the cli on github: https://github.com/dotnet/cli

[christianrondeau]

I have started a branch, and it compiles on my machine, but I will need some help to make sure it works: https://github.com/christianrondeau/termux-packages/tree/dotnet-dev/packages/dotnet-dev

I searched for high level instructions on how to:

1. Test the package I just built on Termux on my Android device. How can I do that? Should I just copy the files and "trust" that it'll work once on Termux's apt repo?
2. Clarifications on the HOSTBUILD; should every device build it, or can I have Termux's repo host the binaries?

A few links to get started would be very helpful, rather than fiddling (and probably making easy to avoid mistakes)

Thanks! Once I have the information I need, I might contribute to the documentation once I understand all pieces.

[vishalbiswas]

After building the package, you can find its deb package(s) in the termux-packages/debs folder of your cloned git repo.
Make sure you have built the package for your devices' architecture. If not run build-package.sh -a <arch> <package> replacing arch with the actual arch.
Copy the deb file(s) over to your device. Install them with dpkg -i <deb_filename>. If the package dependencies haven't been met, run apt install -f.
Then, if you have compiled it correctly, you can run the dotnet executable.

[christianrondeau]

Thank you very much @vishalbiswas - I should have enough to get going for a while :) I'm still trying to understand the relationship between .Net Core repositories and their apt-get counterpart, but I'll reach out if I get stuck.

[cydhaselton]

I've actually built coreclr in termux on device, as well as the necessary bits of corefx. Unfortunately I failed to push commits to my forked coreclr repo so I have to rebuild from scratch.
I can post back once I'm done.

[christianrondeau]

@cydhaselton that would be amazing, I'm still trying to figure out the build part of dotnet-cli (works from a checkout, not from their release tar file for multiple reasons), the relationship with the three .deb files generated in the Microsoft Ubuntu release as well as the subtleties of Termux itself :) Also the time I can put on this per day is near to zero so that will probably take forever! Hopefully I'll learn something from this though.

Let me know if I can help, I'll continue slowly progressing on my branch in the meantime.

[christianrondeau]

Small info : dotnet/cli master builds, and /t:Compile skips tests correctly... but the v1.0.0-preview2.1 tag does not on Ubuntu x64.

So either we build on a custom commit rather than the release, or we monkey patch dynamically. Or I got it wrong :P

I'll continue my investigation.

[cydhaselton]

@christianrondeau: Best of luck with your efforts...I'm still banging my head against this, as I'd like to get Powershell running in Termux.
I will say that, from what I understand, the key build is System.Private.Corelib.dll; this can't be built on an "unsupported" device (no idea what constitutes an unsupported device) and is key to running various bits of .NET core.

If you are ever able to build it for Termux let me know. I'd be more than happy to test.

EDIT: So you have a dotnet/cli that runs on Termux? Care to share?

[christianrondeau]

Not yet, no - I have the build-package.sh building dotnet/cli correctly (pushed this morning), but I'm now trying to understand what build-package.sh does after the build, and what files should I move where for the rest of the build process to work (like I said, very small steps every day!)

There is a bunch of output folders generated by the dotnet/cli build, with multiple stages, .deb files and more and looking at other termux packages, there's some magic that "move files around" between stages that I don't understand, so I'm pretty much reading scripts for now. Once I clarify how to get that build process going through the end, I'll be able to try the executable on my Android device and report back.

[vishalbiswas]

@christianrondeau build-package.sh steps:
0. Download source

1. Configure source
2. Run make, or your overrided function
3. Run make install
   This will get all the compiled and/or other configs, etc from elsewhere and put them into the massage dir. This directly has every file which goes into the final package.
   If your project is not based on Makefile, be sure to override termux_step_make_install to install all required files under $TERMUX_PREFIX, to ensure they are included in the package.
4. Massage package
5. Create package

[christianrondeau]

Thanks again @vishalbiswas, this was indeed my understanding (but I prefer knowing this rather than just relying on my guesses). Where I am at (for those who are interested):

Lookin at the Ubuntu distribution of .NET core, I see the .deb file referenced in https://apt-mo.trafficmanager.net/repos/dotnet-release/dists/xenial/main/binary-amd64/Packages contains:

• dotnet-sdk-ubuntu.16.04-x64.1.0.0-preview2.1-003155.deb
  • usr
    • share
      • doc
      • dotnet
      • man
• dotnet-sharedframework-ubuntu.16.04-x64.1.1.0-preview1-001100-00.deb
  • usr
    • share
      • doc
      • dotnet
• dotnet-hostfxr-ubuntu.16.04-x64.1.1.0-preview1-001100-00.deb
  • usr
    • share
      • doc
      • dotnet
• dotnet-host-ubuntu.16.04-x64.1.1.0-preview1-001100-00.deb
  • usr
    • bin (contains the dotnet-ci binary)
    • share
      • doc
      • dotnet
      • man

And when I build locally .NET, if I look at https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/developer-guide.md#buildingrunning I can see I need the stage 2 output, which looks like this (excluding third party notices and license files):

• stage2
  • dotnet (the executable)
  • host (only contains fxr/1.0.1/libhostfxr.so)
  • sdk (contains 1.0.0-preview3-000001/ and lots of files)
  • shared (contains Microsoft.NETCore.App/1.0.1/ and lots of files)

So two things I'm not sure about.

1. I have a single git repository, which looks like is actually generating the files of the dotnet-host-ubuntu.16.04-x64.1.1.0-preview1-001100-00.deb file.
2. The output files do contain the executable, but the file structure is completely different

So my next steps are to:

1. Try to copy just the dotnet executable, like the host deb file, in the massage folder and see what happens,
2. Test it on my device, and hopefully get a helpful error message saying that something's missing!

It's moving forward!

[christianrondeau]

I can now build the .deb file successfully! But here's my first roadblock. I copied the list of dependencies from the ubuntu .Net Core target, and I tried to install them. Most of them are not available for termux (see output below). Does this mean I'm screwed?

Reading package lists...
Building dependency tree...
Reading state information...
Package libc6 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

Package libcurl3 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

Package libgcc1 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

Package libgssapi-krb5-2 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

Package libicu55 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

Package liblldb-3.6 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

Package liblttng-ust0 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

Package libssl1.0.0 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

Package libstdc++6 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

Package libunwind8 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

Package libuuid1 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

Package zlib1g 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

[christianrondeau]

Skipping dependencies using dpkg --ignore-dependencies shows me I got something wrong even before getting dependencies (on termux) :

$ dpkg -i --ignore-depends=... dotnet-dev_1.0.0-preview2.0.1-0_aarch64.deb
(Reading database ... 8408 files and directories currently installed.)
Preparing to unpack .../dotnet-dev_1.0.0-preview2.0.1-0_aarch64.deb ...
Unpacking dotnet-dev (1.0.0-preview2.0.1-0) over (1.0.0-preview2.0.1-0) ...
Setting up dotnet-dev (1.0.0-preview2.0.1-0) ...

$ dotnet
-bash: /data/data/com.termux/files/usr/bin/dotnet: cannot execute binary file: Exec format error

I'm on a S7 (aarch64), I compiled on Ubuntu 16.04 x64, and I took the file from the termux-packages/debs folder.

The built executable works on Ubuntu, but the massaged version spits out (on ubuntu) :

$ ~/.termux-build/dotnet-dev/massage/data/data/com.termux/files/usr/bin/dotnet
realpath(): Invalid argument
Failed to resolve full path of the current executable [/proc/self/exe]

I guess this part is normal, but I can't say for sure.

Not sure where to go from there. Any idea?

[vishalbiswas]

@christianrondeau Turn off HOSTBUILD. From my understanding, hostbuild will build for the build machine. It should only be enabled for arch independent and/or packages that don't require libc (I'm not sure). Also remove libc6 from depends list, termux uses system provided libc, bionic. Change libcurl3 to libcurl and also remove version requirements from them.
Multiple packages in your Depends array are not available for termux yet. You may need yo port them, too, or disable respective features before compiling.

[christianrondeau]

HOSTBUILD is already off: https://github.com/christianrondeau/termux-packages/blob/dotnet-dev/packages/dotnet-dev/build.sh

For the librairies, it makes sense and I can work through them, thanks.

I'm still stumped for Exec format error though.

I'll try cleaning my environment and make sure it's not a copy error on my part...

[vishalbiswas]

@christianrondeau That Exec format error is because its built for your build machine (probably). I think the Compile command implicitly uses your system gcc and friends. There must be a way to set them to the toolchain ones. You can run readelf on the executable to see what's wrong.

[christianrondeau]

I rebuilt it to make sure. When I extract the generated deb file from termux-packages/debs` on ubuntu, it says:

$ ./data/data/com.termux/files/usr/bin/dotnet
realpath(): Invalid argument
Failed to resolve full path of the current executable [/proc/self/exe]

Which shows it is indeed the massaged version. I also see in build-package.sh output that the architecture is aarch64.

When I force-install it on Termux (and ignore dependencies):

$ dotnet
-bash: /data/data/com.termux/files/usr/bin/dotnet: cannot execute binary file: Exec format error

Either I misunderstood what target arch to use when building the. NET Core source (right now it's ubuntu 16.04 x64), or the build-package.sh script is not yet configured correctly.

Any ideas?

[vishalbiswas]

@christianrondeau run readelf -h which dotnet``

[christianrondeau]

Here's the output in Termux on my S7:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x40c980
  Start of program headers:          64 (bytes into file)
  Start of section headers:          150432 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         31
  Section header string table index: 28

Fun fact: I piped the command output to termux-clipboard-set and pasted here. Termux is awesome.

I also ran file:

/data/data/com.termux/files/usr/bin/dotnet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

[christianrondeau]

I think I see what I misunderstood; build-package.sh does not magically make programs work on aarch64; I still need to compile for ARM before build-package.sh massages the output (which is obvious at this point, but wasn't at the beginning). So, I know where to go from there. I'm linking a few items on .NET Core's project, since it doesn't really have anything for targeting ARM, I'll have to monkey patch something.

• https://github.com/dotnet/cli/issues/2556
• https://github.com/dotnet/coreclr/issues/3977

@cydhaselton if you have stuff to share, that'll help.

So, I'm afraid I'm quite a few steps back. I now need to find how to target ARM/aarch64 in the .NET Core CLI before moving forward on the Termux side. Thanks, I'll keep this thread updated. Hopefully my dream of developing .NET Core apps on my phone with Vim is not too far fetched!

---

Update: It is on Microsoft's roadmap for Q4 2016 - Q1 2017: https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/ which will make things much easier... I'll still try in the meantime!

[vishalbiswas]

It would be better to port mono, until upstream .Net Core adds support for arm.

[christianrondeau]

@vishalbiswas that would not work for my purposes, my objective is to build "Standard" .Net Core apps (no dependency on an installed. Net frameworks) rather than the "full" framework.

I see that arm is actually kind of supported in the master branches, so I can probably get at least a non official build of it and fiddle with it. So when they're ready, I will be too :)

[christianrondeau]

Here's the overview of what I found on how to build it on ARM:

• coreclr: https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux-instructions.md - this is the os/arch-specific "core" of .Net Core. I can build it for ARM.
• corefx: https://github.com/dotnet/corefx/blob/master/Documentation/building/cross-building.md - These are all the librairies of .Net Core apps. It looks like it's trying to download cli, I should but can't build it for arm.
• cli: It's the dotnet executable (for building, running and creating projects). This is confusing, it downloads binaries that are not arm-compatible, and I can't find how to make the build process use arm assemblies, or whether there are efforts to cross compile it.

On other OSes than Ubuntu/Debian, there is a single "apt" instead of the four described before, so that might be the way to go here. But I feel like too many pieces are missing to realistically use cli on arm today ... So maybe this issue will have to wait a few months :(

I'll continue fiddling, my only hope now is to at least get the framework (coreclr/corefx) working on this branch, so that it will be easier once cli supports arm to finish these build scripts. If anyone have a better idea, I'm open to them.

[cydhaselton]

@christianrondeau I've got a working port of mono on Termux, so I've been attempting to build parts of cli using the Roslyn csharp compiler (which runs with the mono runtime) or mono's xbuild (since the cli directory contains proj files). It's hit and miss: xbuild doesn't want to use relative paths and throws a permissions error when accessing "/data" and the source wasn't structured to build using the commandline csharp compiler. Or I'm not familiar enough with the csharp compiler…which is also possible.

I'm currently re-building coreclr on device so that I can upload the patched sources to github. I've already got corefx built and the changes pushed to my fork.

If you're motivated you can search the dotnet/cli gitter archives for my efforts to figure out what in the cli source tree can be built using the utilities I've already built for Termux.

[vishalbiswas]

@cydhaselton How about building in chroot on device?

[cydhaselton]

@vishalbiswas: Interesting idea. I've built in a completely chrooted environment before but it was pre-installed (kbox); I'd have to figure out how to set it up.

I'll give it a shot once coreclr is done.

EDIT: Would there be issues with running a program built in proot in regular termux-space?

[christianrondeau]

@cydhaselton So what you're saying, is that you tried to use a custom mono build for Termux, to run the Roslyn compiler and then use that to build dotnet cli? My head hurts :)

So I see that your branch has a termux-fix-shebang #! so that it builds on Termux, which bring the question: where does build-package.sh actually run? I thought it was on Ubuntu 16.04. Also, I looked at your fork and I see that it's 2674 commits behind upstream's master, so it might be worth it to see if their branch now works as-is (it's supposed to, if I read their doc right).

Anyway, I got coreclr building for arm64 already without any custom branches nor monkey patching, so I guess I can already push this, which brings the question: Should we do like A) Ubuntu, and provide a different package for clr, fx and cli, or B) build and bundle everything together? I'm not sure yet because is looks like there are cross-dependencies between them. Splitting would allow easier tracking than this mega-thread. Probably something to discuss after it works :)

I feel like I'm way out of my league with this, but there's movement and lots of learning, so it's all good I guess!

[vishalbiswas]

build-package.sh runs on Ubuntu. He is talking about extracting and building cli from source on device.
As for the package layout, you could create a main package i.e. dotnet and have corefx.subpackage.sh and coreclr.subpackage.sh

[cydhaselton]

Yeah, I build everything on-device; I don't have easy access to Linux builds (and yes I do know about the various prebuilt VMs out there…its a space issue) and my tablet is always with me.

I'm aware my branch is behind; I have a limited knowledge of git and a full plate at work so updating the branch is on a to-do list for now.

My recommendation would be to provide the packages separately with dependencies where appropriate. The various moving parts of .NET can be huge.

@christianrondeau Yup, that's about right. Getting rosyn to work with mono was easy; basically someone told me that roslyn would execute under the mono runtime. The difficult part is figuring out all of the dependencies for .NET Core, which repos contain which dependencies and exactly what is needed to run Powershell…which is my ultimate goal.

Let me know if/when the coreclr is available for termux; I'll quit the build I'm currently working on and focus on corecli

[spaceman5]

Can anyone from the persons who worked on this please give a rough estimate how many months of work (assuming full time work is done) is needed for such a project?

[spaceman5]

After going over the messages in #1097, it's not so clear what is the current situation - was it complete?

[spaceman5]

BTW,
you all probably want to read this:
https://devblogs.microsoft.com/dotnet/introducing-net-5/

[nathanpovo]

From this article it seems that net 6.0 will support building for android:

.NET 6.0 will ... add net6.0-ios and net6.0-android.

[ghost]

it seems that net 6.0 will support building for android

Easy way to cross-compile to Android host whole dotnet framework and compilers? We need a full package, not just runtime/libs.

[nathanpovo]

I found some instructions in the https://github.com/dotnet/runtime repository on how to build the dotnet runtime for linux arm64 which I managed to follow and successfully execute. However, I am not sure if that is enough to be able to use the dotnet cli in termux.

The same repository also has some instructions on how to build the runtime for android here. Unfortunately, these instructions seem to be outdated. I have asked for some up-to-date instructions in the issue that is used to track building the runtime for android (dotnet/runtime#33237 (comment)).

[shaunawins]

I've just started using my phone for c# development with mono, and I was wondering if there's been any progress on this so I can start using dotnet core instead?

[Jisu-Woniu]

.NET 6 provides native arm64 binary. So is there a possibility to install it on termux?

[kevin100702]

Successfully compiled and ran dotnet web app on Android!

I found this

[kevinloustau]

+1

[Jisu-Woniu]

Successfully compiled and ran dotnet web app on Android!

I found this

This one is achieved in an Ubuntu environment through proot-distro, however what I hoped is running dotnet directly in termux environment.

[kevinloustau]

Dotnet v7 is available on linux arm64 https://dotnet.microsoft.com/en-us/download/dotnet/7.0

[afonsoft]

pkg install mono -y;
wget https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.sh -q;
chmod +x dotnet-install.sh;
./dotnet-install.sh -c LTS;
./dotnet-install.sh -c STS;
echo 'export DOTNET_ROOT=$HOME/.dotnet' >> ~/.bashrc
echo 'export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools' >> ~/.bashrc

[afonsoft]

pkg install mono -y; wget https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.sh -q; chmod +x dotnet-install.sh; ./dotnet-install.sh -c LTS; ./dotnet-install.sh -c STS; echo 'export DOTNET_ROOT=$HOME/.dotnet' >> ~/.bashrc echo 'export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools' >> ~/.bashrc

This install but not run dotnet, and in install have many warring with dependencies.

Need this dependencies https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu#dependencies

When you install with a package manager, these libraries are installed for you. But, if you manually install .NET or you publish a self-contained app, you'll need to make sure these libraries are installed:

• libc6
• libgcc1
• libgcc-s1 (for 22.x)
• libgssapi-krb5-2
• libicu55 (for 16.x)
• libicu60 (for 18.x)
• libicu66 (for 20.x)
• libicu70 (for 22.04)
• libicu71 (for 22.10)
• liblttng-ust1 (for 22.x)
• libssl1.0.0 (for 16.x)
• libssl1.1 (for 18.x, 20.x)
• libssl3 (for 22.x)
• libstdc++6
• libunwind8 (for 22.x)
• zlib1g

[afonsoft]

https://github.com/its-pointless/gcc_termux

[truboxl]

Hi all, we will adopt semi source build approach to build .NET to match other Linux distro offerings (Ubuntu, Fedora, Alpine) as:

1. Unreleased .NET 8 is heading towards that direction should we want to package that
2. All past methods of building .NET for Android is broken or not comprehensive

AFAICT the minimum viable version offered will be .NET 7. Anything lower will involve a lot more patches. PRs are welcomed until the version EOL.

This is not a guarantee that the package is on the way. Building all .NET components:

1. Is Complex
2. Uses a lot of disk spaces
3. May not even work for Android (missing support, different behaviour from Linux, etc.)

Hence will disable building them individually for the short term. We will learn as we build along the way. PRs are definitely welcomed after the initial package is landed.

[duncanawoods]

Awesome @truboxl - looking forward to helping out if I can!

[vzarytovskii]

Hi all, we will adopt semi source build approach to build .NET to match other Linux distro offerings (Ubuntu, Fedora, Alpine) as:

1. Unreleased .NET 8 is heading towards that direction should we want to package that
2. All past methods of building .NET for Android is broken or not comprehensive

AFAICT the minimum viable version offered will be .NET 7. Anything lower will involve a lot more patches. PRs are welcomed until the version EOL.

This is not a guarantee that the package is on the way. Building all .NET components:

1. Is Complex
2. Uses a lot of disk spaces
3. May not even work for Android (missing support, different behaviour from Linux, etc.)

Hence will disable building them individually for the short term. We will learn as we build along the way. PRs are definitely welcomed after the initial package is landed.

Building it from source shouldn't be that complex. Hmu if you need any help with it.

[PopSlime]

.NET 8 has been released. Any progress on this?

[ErrrorMaxx]

Any progress on .NET for Android?

[vincentkam]

I was experimenting with this and sort of got the dotnet binary to run, but not to the point where anything useful can be done.

➜  ~ cat ./install-dotnet.sh
DOTNET_FILE=./storage/downloads/dotnet-sdk-8.0.204-linux-arm64.tar.gz
export DOTNET_ROOT=$(pwd)/.dotnet

mkdir -p "$DOTNET_ROOT" && tar zxf "$DOTNET_FILE" -C "$DOTNET_ROOT"

export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
➜  ~ ./install-dotnet.sh
➜  ~ cd .dotnet
➜  .dotnet file ./dotnet
./dotnet: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=aa01bea55c0e51e5db135ddc4fba6625cf812507, stripped
➜  .dotnet ./dotnet
zsh: no such file or directory: ./dotnet
➜  .dotnet grun
Help message from glibc-runner v2.0

glibc-runner - launcher for working with the glibc shell or with a glibc-based binary

Options:
 --help      -h  print help message
 --info      -i  print information about the running glibc-runner shell
 --shell     -s  run the glibc-runner shell or a command from that shell
 --teg       -t  enable the use of termux-exec-glibc in the glibc-runner shell
 --configure -c  configure the binary to run on the device
 --findlib   -f  find libraries for the binary
 --no-linker -n  don't use dynamic linker to launch binary
 --debug     -d  [1|2|3|4]  launch binary or shell under strace

Example: glibc-runner [-c|-f|-n] ./binary || grun [-s|-n|-t] [gcc -v]

Bug report: https://github.com/termux-pacman/glibc-packages/issues
➜  .dotnet grun -f ./dotnet
Message from glibc-runner: searching for libraries...
Message from glibc-runner: searching libraries was successful
Error: cannot execute dotnet when renamed to ld-linux-aarch64.so.1.
➜  .dotnet grun -c ./dotnet
➜  .dotnet file ./dotnet
./dotnet: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /data/data/com.termux/files/usr/glibc/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=aa01bea55c0e51e5db135ddc4fba6625cf812507, stripped
➜  .dotnet grun -s ./dotnet

Usage: dotnet [options]
Usage: dotnet [path-to-application]

Options:
  -h|--help         Display help.
  --info            Display .NET information.
  --list-sdks       Display the installed SDKs.
  --list-runtimes   Display the installed runtimes.

path-to-application:
  The path to an application .dll file to execute.
➜  .dotnet
➜  .dotnet grun -s ./dotnet --info
.NET SDK:
 Version:           8.0.204
 Commit:            c338c7548c
 Workload version:  8.0.200-manifests.9f663350

Runtime Environment:
 OS Name:     Linux
 OS Version:
 OS Platform: Linux
 RID:         linux-arm64
 Base Path:   /data/data/com.termux/files/home/.dotnet/sdk/8.0.204/

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      8.0.4
  Architecture: arm64
  Commit:       2d7eea2529

.NET SDKs installed:
  8.0.204 [/data/data/com.termux/files/home/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.4 [/data/data/com.termux/files/home/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.4 [/data/data/com.termux/files/home/.dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

But whenever I try to do anything, including --help or new, I get the following:

➜  .dotnet grun -s ./dotnet --help
System.IO.IOException: The system cannot open the device or file specified. : 'NuGet-Migrations'
   at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, Boolean& createdNew)
   at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
   at NuGet.Common.Migrations.MigrationRunner.Run(String migrationsDirectory)
   at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(IFirstTimeUseNoticeSentinel firstTimeUseNoticeSentinel, IAspNetCertificateSentinel aspNetCertificateSentinel, IFileSentinel toolPathSentinel, Boolean isDotnetBeingInvokedFromNativeInstaller, DotnetFirstRunConfiguration dotnetFirstRunConfiguration, IEnvironmentProvider environmentProvider, Dictionary`2 performanceMeasurements)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

See the attached strace via ➜ .dotnet grun -s -d ./dotnet --help
strace.txt

Possibly related to dotnet/runtime#91987 ?