The lang/linux-dotnet-cli port has installed a
This may seem to suggest that it expects something like ahost
The
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
Edit
Did it actually check under
This appears to be so. With the Linux virtual filesystem emulation mounted at each usual mount point (e.g dev, proc, sys) under the
Solved. Will try out the
dotnet
under /usr/local/bin
. When I run this dotnet
cmd, I see the following output:
Code:
$ 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 /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:
Code:
# service linux onestart
Solved. Will try out the
dotnet
sub-cmds shortly ...