Using dotnet the FreeBSD + the frank dotnet crossbuild + bike, produces "error unable to get executable name error"

[devosalain]

Trying out a basic bike-sbcl program produces ,

...................Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                    {1005E200A3}>:
  Unable to get executable name

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1005E200A3}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SIMPLE-ERROR "Unable to get executable name" {1004A53033}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<SIMPLE-ERROR "Unable to get executable name" {1004A53033}>)
2: (INVOKE-DEBUGGER #<SIMPLE-ERROR "Unable to get executable name" {1004A53033}>)
3: (ERROR "Unable to get executable name")
4: (GET-EXE-PATH)
5: (FIND-CORECLR)

OS : FreeBSD 14.0 Dotnet: TheFrank Crossbuild. https://github.com/Thefrank/dotnet-freebsd-crossbuild https://github.com/Thefrank/dotnet-freebsd-crossbuild/releases/tag/v7.0.405 sbcl: v 2.3.1

[Lovesan]

I'll copy my comment from Reddit in here:

FreeBSD isn't officially supported by .NET. I wasn't even aware that you could even build it here. However, seems like there's a community port now.

So porters for my library are also welcome!

So, to port it to FreeBSD, you need to make a patch, that requires several additions, and probably some nontrivial signal hackery.

First, you should probably add coreclr-freebsd to *features*.

https://github.com/Lovesan/bike/blob/master/src/features.lisp

Next, you need to implement get-exe-path function for your OS. It retrieves the running executable path which is required for .NET runtime initialization:

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/internals-ffi.lisp#L264

(the real reason for your error comes from this function)

Probably you should check '/proc/curproc/file', and in case procfs does not exist in the FreeBSD installation, the library is running on, then you would probably need some syscall invocation using CFFI.

Now, to the hardest part.

As you can see from the README, the library actually does some fancy lowlevel signal hackery when it comes to running it on Linux. FreeBSD port would most likely require the same level of workarounds. (actually, macOS would require that too, but I haven't had much access to that OS recently)

First, you should write some signal numbers for FreeBSD and probably reuse some specific function from here

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/ffi.lisp#L92

Next, you should verify, what specific signal numbers are critically required by dotnet, and write some save-restore logic akin to the following:

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/host.lisp#L234

You should probably look at FreeBSD .NET port and the patches it applies to the .NET runtime, to look up for this.

At least SIGCHLD and INJECT_ACTIVATION_SIGNAL should be restored to .NET handlers.

INJECT_ACTIVATION_SIGNAL is used by .NET for some thread-related hackery and equals SIGRTMIN on Linux and SIGUSR1 on OSes where SIGRTMIN is not defined in C headers.

It is defined here in the original .NET source.

https://github.com/dotnet/runtime/blob/52c14fb8d01ddd293a0710642aa1e7ef3a438687/src/coreclr/pal/src/exception/signal.cpp#L56

Finally, you should also check where the library uses coreclr-whatever feature, e.g. coreclr-linux and coreclr-macos specifically, and whether some things need to be fixed additionally (some pathnames, file extensions, etc, but probably FreeBSD does not differ from Linux in that regard, and the library already does handle most of the things based on coreclr-windows presence).