Solved Using the linux-dotnet-{runtime, cli, sdk} ports under host localbase

[neogeo]

The lang/linux-dotnet-cli port has installed a dotnet under /usr/local/bin. When I run this dotnet cmd, I see the following output:

$ dotnet  --help

Failed to resolve full path of the current executable [/proc/self/exe]

This may seem to suggest that it expects something like a linprocfs filesystem mounted at the host /proc directory?

The /usr/local/bin/dotnet is a symlink that resolves to /usr/local/share/dotnet/dotnet. If this dotnet is installed under the FreeBSD localbase but would expect a virtual filesystem configuration like would typically be mounted under the linuxbase path -- e.g under /compat/linux for dev, proc, sys virtual filesystems in the Linux ABI support -- is there a walkthrough available showing how this could work out? I'm not certain if other ports would be able to handle a linprocfs mount under the host /proc filesystem, or what other cross-OS concerns might show up beyond this initial error message in the dotnet cmd.


While I understand that there's Mono available for a C# compiler, also for msbuild and other tooling on FreeBSD, I'm not certain of whether Mono is still being actively developed at Xamarin/Microsoft.

If in order to make use of these existing cross-ports for dotnet support on FreeBSD, there is this first matter of the virtual filesystem it seems to need for the dotnet cmd.


Edit

Did it actually check under compat.linux.emul_path (sysctl mib) for what it shows at the console as /proc/self/exe ? Will test this locally.

This appears to be so. With the Linux virtual filesystem emulation mounted at each usual mount point (e.g dev, proc, sys) under the compat.linux.emul_path path, then the dotnet cmd does not present that error message. Typically, this could be resolved by running the following, before the dotnet cmd:

# service linux onestart

Solved. Will try out the dotnet sub-cmds shortly ...