Dotnet support for FreeBSD

[lillo42]

Hey folks, I'm searching for dotnet on FreeBSD, I found some issues related to that but something isn't clear to me what is missing for dotnet to be completely compatible with FreeBSD (and when a version is released is to be released for FreeBSD too)

[neon-sunset]

There are no Microsoft-maintained FreeBSD builds. There is, now, however https://www.freshports.org/lang/dotnet/

In theory, it should be accessible with just pkg install lang/dotnet.

[am11]

FreeBSD is a community supported platform in .NET. You can install it from ports which @neon-sunset pointed out. It uses the same source-build approach as linux distros (https://github.com/dotnet/dotnet). If you run into a problem, like for any platform, open an issue in runtime repo (existing issues: https://github.com/dotnet/runtime/issues?q=is:issue+label:os-freebsd).

what is missing for dotnet to be completely compatible with FreeBSD

@Thefrank may have a better answer, but it is usable as-is and has been for a while. Last time I tried compiling basic apps, dotnet(1) was working fine on FreeBSD host as well as dotnet(1) for linux was working under Linuxulator (by disabling W^X). Haven't tried in a while so YMMV.

[Thefrank]

what is missing for dotnet to be completely compatible with FreeBSD

Depending on how you see "completely compatible" either nothing at all or so many interlocking things that this topic would quickly expand far beyond the question.

As @am11 said the dotnet in FreeBSD's ports is usable right now for basic needs. You will need to turn off the ASLR flag for any binaries you generate with it (elfctl -e NAME). If you want to do serious development with it for/on FreeBSD and want to use anything more than the SDK (e.g., using dotnet tool ...) you will run into typical THING-is-supported-by-the-community limitations as developers are hesitant to build for/support a platform that is not officially supported by the language they are using.

@lillo42 I hope that clears things up without getting too complicated!

[am11]

@Thefrank, thanks!

Is there an issue tracking ASLR / elfctl -e NAME, and does it apply to AOT published binaries?

We had a similar issue with linux binaries during the debugging (in diagnostics repo) a while back and I opened llvm/llvm-project#61899. Workaround was clear, but I didn't knew FreeBSD had it for even non-debug run. Something we could fix in apphost (assuming AOT binaries run fine without disabling ASLR).

[am11]

Just tested in CirrusCI terminal access, FreeBSD 14 amd64:

$ uname -a
FreeBSD cirrus-task-5661843576848384 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

$ pkg install -y dotnet-8.0.0

$ dotnet new webapi -n w2
$ cd w2
$ dotnet publish -o dist -p:PublishSingleFile=true

$ ls dist
appsettings.Development.json    w2
appsettings.json                w2.pdb

$ file dist/w2
dist/w2: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400097), FreeBSD-style, BuildID[sha1]=2cb4a216e1fa2ca413fe0119fd0a092ccf7d44d5, stripped

# check if ASLR is enabled on the system (yes it is)
$ sysctl kern.elf64.aslr.enable
kern.elf64.aslr.enable: 1

# check if binary has ASLR disabled (no it is not)
$ elfctl dist/w2
File 'dist/w2' features:
noaslr          'Disable ASLR' is unset.
noprotmax       'Disable implicit PROT_MAX' is unset.
nostackgap      'Disable stack gap' is unset.
wxneeded        'Requires W+X mappings' is unset.
la48            'amd64: Limit user VA to 48bit' is unset.

$ dist/w2
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /tmp/cirrus-ci-build/w2

Seems to be running with ASLR based on this simple test. 👀

[Thefrank]

EDIT: This should've been a reply to @am11 above but it turns out I can't click the right button to post replies correctly

https://github.com/freebsd/freebsd-ports/blob/698eadbe278c0e8c50da6082994e16bb4910a398/lang/dotnet/Makefile#L99
was added because of issues brought up #14537 (comment) and reproduced #14537 (comment)

Looping the script found in the second comment, I have not been able to reproduce the issue on FreeBSD 14. For libunwind 1.8 I still had ASLR off system-wide on my build system as I was sometimes hitting crashes. The current libunwind on FreeBSD is 20240221 which is 1.8.1 and the one used for the test just now. I try something more complex with AZP and some dotnet builds a bit later and edit this with an update

EDIT: neither the newest versions of jellyfin nor azure-pipelines-agents experienced crashes during the building or testing process. Maybe it was libunwind after all? 🤷

[Thefrank]

so i thought we have to wait for .NET 9 (for source builds to provide ilc packages).

On the FreeBSD this was proposed to modify the dotnet port to add NuGets to their own location and register it with dotnet. It should be sufficient for .NET8 until .NET9 where it can be re-approached (bundled back package vs bundled by SDK)

It should cover all the required NuGets:

%%NUPKG%%dotnet/packages/Microsoft.AspNetCore.App.Runtime.freebsd-x64.8.0.0.nupkg
%%NUPKG%%dotnet/packages/Microsoft.NETCore.App.Crossgen2.freebsd-x64.8.0.0.nupkg
%%NUPKG%%dotnet/packages/Microsoft.NETCore.App.Host.freebsd-x64.8.0.0.nupkg
%%NUPKG%%dotnet/packages/Microsoft.NETCore.App.Runtime.freebsd-x64.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.DotNet.ILCompiler.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.DotNetAppHost.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.DotNetHost.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.DotNetHostPolicy.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.DotNetHostResolver.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.ILAsm.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.ILDAsm.8.0.0.nupkg
%%NUPKG%%dotnet/packages/runtime.freebsd-x64.Microsoft.NETCore.TestHost.8.0.0-rtm.23531.3.nupkg

Projects that come with their own nuget.config will still need to be modified manually to include the FreeBSD specific NuGet location but I can not see that as being much of an issue.

[am11]

Yup, if they are using <clear/> statement in their feed, then it won't inherit the global.json. If they restored a project once before the restoring using global nuget config, it will hit the local cache, but it's a clunky workflow I agree. 😅

Regarding https://reviews.freebsd.org/D44561, is the current behavior of cirrus-ci (unable to find ILCompiler package) expected (i.e. we have to wait for next quarter)? I will try to fast track from quarterly feed next.

[am11]

Upgrading from quarterly to latest didn't help on cirrus-ci:

$ sed -i '' -e '/^\[quarterly\]/,/^$/ s/^url:/#url:/' -e '/^\[latest\]/,/^$/ s/^#url:/url:/' /etc/pkg/FreeBSD.conf
$ pkg update && pkg upgrade -y && pkg install -y dotnet-8.0.0
$ dotnet new webapiaot -n w1
dotnet new webapiaot -n w1
...
The template "ASP.NET Core Web API (native AOT)" was created successfully.

Processing post-creation actions...
Restoring /tmp/cirrus-ci-build/w1/w1.csproj:
  Determining projects to restore...
/tmp/cirrus-ci-build/w1/w1.csproj : error NU1101: Unable to find package runtime.freebsd-x64.Microsoft.DotNet.ILCompiler. No packages exist with this id in source(s): nuget.org
  Failed to restore /tmp/cirrus-ci-build/w1/w1.csproj (in 688 ms).
Restore failed.
Post action failed.
Manual instructions: Run 'dotnet restore'

Perhaps the post-install step isn't running?

[Thefrank]

Regarding https://reviews.freebsd.org/D44561, is the current behavior of cirrus-ci (unable to find ILCompiler package) expected (i.e. we have to wait for next quarter)?

Yes. It is still waiting to be approved/commited.

Once commited you will have to wait until next quarter unless you want to switch to using latest package mirror. latest will pick up the new package once it reaches pkg mirrors (~1-4 days after commit). quarterly is the default and while latest will be just as reliable I like to keep local build systems on quarterly unless I absolutely need something faster due to demands (e.g., the rare rust project that require the absolute newest everything). Both quarterly and latest receive security updates for packages.

[am11]

Ah, didn't noticed "Needs Review" status. 😅

Yup, true for local dev environment, but the CirrusCI instances are of a throw-away sort; we can modify it however we see fit for the job, once it exists, it gets disposed. So latest in that sandbox-y environment is fine (at least I'm not building anything production-ready there yet).