Building the .NET Core SDK on FreeBSD

[joperator]

I'm trying to build the .NET Core SDK on FreeBSD but I'm having trouble with the documentation. The documentation says I just have to initialize the submodules in the source-build repo and run ./build.sh. But this produces only the following output:

Unsupported OS 'FreeBSD' detected. Downloading linux-x64 tools.
Installing dotnet cli...
Installing dotnet 3.0 preview1 cli...
Restoring BuildTools version 3.0.0-preview4-04104-01...

Later in the documentation it says that

git submodule update --init --recursive [...] will initialize the submodules and clone the repos under the src folder if they haven't been initialized.

But after running this command, my src folder contains only the subfolders netcorecli-fsc and reference-assemblies, which are not all required repos I think. As the documentation says, I expected at least core-setup, standard, corefx and coreclr to be cloned into the src folder. This would also explain why there is no bin folder in my source-build repo after running ./build.sh as described in the documentation. If the scripts don't work under FreeBSD, I expect at least an error, otherwise I assume that everything has been built, which is not the case here.

So, am I doing something wrong or is the documentation incorrect or out of date?

[FeodorFitsner]

Thank you for the clarification. I'm continuing with building full SDK according to the guide then.

[FeodorFitsner]

On core-setup step running ./build.sh --configuration Release /p:OSGroup=FreeBSD /p:PortableBuild=true /p:OfficialBuildId=20190913.5 /p:ContinuousIntegrationBuild=true fails with the following errors:

...

  Microsoft.NETCore.App.Runtime -> /usr/home/appveyor-build/dotnet/core-setup/artifacts/packages/Release/specs/Microsoft.NETCore.App.Runtime.freebsd-x64.nuspec

Build FAILED.

/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.DotNet.PlatformAbstractions/Microsoft.DotNet.PlatformAbstractions.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.Extensions.DependencyModel/Microsoft.Extensions.DependencyModel.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.Extensions.DependencyModel/Microsoft.Extensions.DependencyModel.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.Extensions.DependencyModel/Microsoft.Extensions.DependencyModel.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/managed/Microsoft.DotNet.PlatformAbstractions/Microsoft.DotNet.PlatformAbstractions.csproj]
/usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Managed.Core.targets(102,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.MapSourceRoots" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet-sdk/sdk/3.0.100/Roslyn/Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-setup/src/test/Microsoft.DotNet.CoreSetup.Packaging.Tests/Microsoft.DotNet.CoreSetup.Packaging.Tests.csproj]
    0 Warning(s)
    7 Error(s)

What could be the reason for these errors?

[am11]

@FeodorFitsner, could you try appending /p:UsingToolMicrosoftNetCompilers=false to ./build.sh?

@wfurt, is it possible to build the entire suite from scratch to shoot; including the bootstrap/seed project; i.e. there is no (unavoidable) manual step involved? In the pursit of a "clean and automated" product build, I started from very beginning: https://github.com/am11/source-build/blob/release/3.1/.cirrus.yml, but buildbootstrapcli.sh failed during the cp operation after building corefx, due to a "directory not found" error: https://cirrus-ci.com/task/5842677307801600. If it should work, I can investigate, but if buildbootstrapcli.sh is a definite no-go, we can ask @jasonpugsley about the recipe of building the bootstrap project. :)

[wfurt]

I don't know @am11. I started source-build with already constructed bootstrap cli and 3.x and 2.1 packages available. I think we should partition the problem and split creation of bootstrap from building next/current version. Second should be be possible with environmental variables and without any manual step or code modification.

[FeodorFitsner]

@am11 Adding /p:UsingToolMicrosoftNetCompilers=false helped, thank you! However, running ./build.sh --configuration Release /p:PortableBuild=true /p:OfficialBuildId=20190918.4 /p:ContinuousIntegrationBuild=true /p:DisableSourceLink=true on the last core-sdk step gives another errors:

Build FAILED.

/usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/Version.targets(17,5): error MSB4062: The "Microsoft.DotNet.Arcade.Sdk.CalculateAssemblyAndFileVersions" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/netcoreapp2.1/Microsoft.DotNet.Arcade.Sdk.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-sdk/test/Microsoft.DotNet.Tools.Tests.Utilities/Microsoft.DotNet.Tools.Tests.Utilities.csproj]
/usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/Version.targets(17,5): error MSB4062: The "Microsoft.DotNet.Arcade.Sdk.CalculateAssemblyAndFileVersions" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/netcoreapp2.1/Microsoft.DotNet.Arcade.Sdk.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-sdk/src/SdkResolver/SdkResolver.csproj]
/usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/Version.targets(17,5): error MSB4062: The "Microsoft.DotNet.Arcade.Sdk.CalculateAssemblyAndFileVersions" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/netcoreapp2.1/Microsoft.DotNet.Arcade.Sdk.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-sdk/src/Microsoft.Dotnet.Sdk.Internal/Microsoft.Dotnet.Sdk.Internal.csproj]
/usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/RepositoryValidation.proj(29,5): error MSB4062: The "Microsoft.DotNet.Arcade.Sdk.GetLicenseFilePath" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/netcoreapp2.1/Microsoft.DotNet.Arcade.Sdk.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
/usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/Version.targets(17,5): error MSB4062: The "Microsoft.DotNet.Arcade.Sdk.CalculateAssemblyAndFileVersions" task could not be loaded from the assembly /usr/home/appveyor-build/dotnet/core-sdk/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.19463.1/tools/netcoreapp2.1/Microsoft.DotNet.Arcade.Sdk.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [/usr/home/appveyor-build/dotnet/core-sdk/src/core-sdk-tasks/core-sdk-tasks.csproj]
    0 Warning(s)
    5 Error(s)

Any clue? I feel we are so close to having an updated/working script!

[am11]

@FeodorFitsner, this is also the same MSB4062 error, I'd try the same property with core-sdk: /p:UsingToolMicrosoftNetCompilers=false.

@wfurt, right on. I was thinking about creating two interdependent tasks in that YAML: source_build_task depends on bootstrap_source_build_task. There is a 120 minutes limit per task in CirrucCI free tier, I am afraid we will hit it eventually.

[FeodorFitsner]

Adding /p:UsingToolMicrosoftNetCompilers=false didn't help - getting the same errors.

[am11]

This was the revision of core-sdk: ec736cbd54dc2b75a36acda4a7c00e4b99c7d094 when Tomas completed his pull request.

https://github.com/dotnet/source-build/blob/d1dbb1e1eacf1ca1e2dc459f605e26026f09cca9/eng/Version.Details.xml#L117-L120

Previous to that is f08e8bc516c2d598c8b0fba247bf8eac5e329a91. If you are not using one of these revisions, maybe try building both? (ec736cbd5 first)

[FeodorFitsner]

I'm currently getting SDK according to the build guide:

git clone https://github.com/dotnet/core-sdk.git
...
cd ~/dotnet/core-sdk
git checkout release/3.0.1xx
git reset --hard v3.0.100

Could you please elaborate what you mean? Sorry if it's obvious - I'm new to the process.

[am11]

git rev-parse HEAD
04339c3a262a2e313f9431edd3805ce71e08b92e

Sorry, I forgot about resetting to fixed v3.0.100 tag. It is pretty strange then why it fails.

If you have enough space, could you try a separate build via dotnet/source-build repo:

git clone https://github.com/dotnet/source-build --single-branch --branch release/3.0 --depth 1

cd source-build
time ./build.sh

[wfurt]

automation would be good @am11. I'm pretty lazy person. Let's separate this to separate issues. Hopefully we don't need to build fresh bootstrap for every version of .NET. Right now multiple product versions use same cli to build. Since we start with some binaries anyway my suggestion would be to somehow workout automation to create one and perhaps host artifacts somewhere. This is most likely outside of source-build repo. And than have separate effort to automate source-build and publish artifacts. If you really want to you can combine them at some point but I think each of them will face different challenges.

[FeodorFitsner]

@am11 I did git checkout 04339c3a262a2e313f9431edd3805ce71e08b92e in core-sdk directory and the build worked. I've got the resulting packages:

ls artifacts/packages/Release/Shipping/
dotnet-sdk-3.0.100-freebsd-x64.tar.gz           dotnet-sdk-internal-3.0.100-freebsd-x64.tar.gz  freebsd_x64_Release_version_badge.svg
dotnet-sdk-3.0.100-freebsd-x64.zip              dotnet-sdk-internal-3.0.100-freebsd-x64.zip

Now, I'm unpacking created dotnet-sdk-3.0.100-freebsd-x64.tar.gz to ~/dotnet-sdk3 then trying to create and run a new web app with that re-built SDK gives the same error:

$ ~/dotnet-sdk3/dotnet run
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The .NET Core frameworks can be found at:
  - https://aka.ms/dotnet-download

Was Microsoft.AspNetCore.App built during the build process and where it is located if it was?

[wfurt]

That is packaging issue. look at https://github.com/dotnet/source-build/issues/1139#issuecomment-525867361 and update Microsoft.NETCoreSdk.BundledVersions.props

[FeodorFitsner]

You mean commenting out <KnownFrameworkReference Include="Microsoft.AspNetCore.App" ... /> element in /usr/home/appveyor-build/dotnet-sdk3/sdk/3.0.100/Microsoft.NETCoreSdk.BundledVersions.props?

[FeodorFitsner]

Produced on the last core-sdk step dotnet-sdk-3.0.100-freebsd-x64.tar.gz contains only shared/Microsoft.NETCore.App inside, no Microsoft.AspNetCore.App.

[wfurt]

yes. This is because build assumes it will be included but it is not. There may be other ways how to make that right but editing the file should be fastest and sufficient. Once you do first full build, you should have Microsoft.AspNetCore.App available so build + 1 should not need this step.

[FeodorFitsner]

Should that file be updated in bootstrap SDK dir before building core-sdk?

[FeodorFitsner]

@am11 building source-build finishes with error:

$ time ./build.sh
Found bootstrap SDK 3.0.100, bootstrap Arcade 1.0.0-beta.19359.6
grep: /proc/1/cgroup: No such file or directory
+++ dirname ./build.sh
++ cd -P .
++ pwd
+ scriptroot=/usr/home/appveyor-build/source-build
+ '[' false == true ']'
+ /usr/home/appveyor-build/source-build/eng/common/build.sh --restore --build -c Release --warnaserror false -bl /flp:v=diag /p:Projects=/usr/home/appveyor-build/source-build/build.proj
Downloading 'https://dot.net/v1/dotnet-install.sh'
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100/dotnet-sdk-3.0.100-freebsd-x64.tar.gz
curl: (22) The requested URL returned error: 404
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100/dotnet-sdk-3.0.100-freebsd-x64.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.0.100
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
Failed to install dotnet SDK (exit code '1').
        0.69 real         0.09 user         0.12 sys

[wfurt]

You have to have your version on PATH so build scrip can find it to avoid attempt to download it. (script checks if expected version is available). I also set DotNetCoreSdkDir but I'm not sure if that is still needed. (I have my working environment for a while and I don't touch it) Jumping ahead, make sure you have both 3.0 and 2.1 packages ready. I'm not sure if instructions were ever updated to reflect latest needed steps.

It seems like latest Arcade does not need LibGit2Sharp. Was that ported back to 3.0 branch @crummel ? That would avoid another annoying step.

[wfurt]

Hey @am11 . I did take a look and buildbootstrapcli.sh will not work. That only rebuilds native bits and that is not sufficient in our case. It seems like we lost old Wiki page with instructions how to update bootstrap cli in transition to runtime repo. If I find some time I'll try to write some script later this week to automate that.

[wfurt]

I put up back old page how to create bootstrap cli: https://github.com/wfurt/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD

As far as I know there is no good way how to recreate that only on FreeBSD. Best shot would probably be last published sdk for FreeBSD but unfortunately it is too old and not compatible with current build. If we want to automate that @am11, we would need some dual OS setup and build coordinated between them. I'm wondering if wee should turn that to separate project/repo for now. Once that is available, it should feed to source-build and rest should be pretty straight forward.

BTW did you have any luck progressing forward @FeodorFitsner ?

[am11]

@wfurt, I took a look and it seems buildbootstrapcli.sh was really meant for this (build-from-very-scratch) use-case. It uses the linux-x64 tarball as a seed input then replaces the RID here, then overwrites linux native components (from tarball) with just-compiled native components. If I am missing something, please correct me. Otherwise, we can try to fix this script as, in addition to FreeBSD, it will benefit future OSes (like Solaris) and architectures (like MIPS).

[FeodorFitsner]

@wfurt I didn't have a chance to work on this today, but I tried your suggestions yesterday and still was unable to run a simple web application with the same The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found. error. I must be doing something wrong. Is there any chance @jasonpugsley could modify the guide to include building ASP.NET Core SDK as well?

[jasonpugsley]

@FeodorFitsner I'll take a look at what is required to have ASP.NET Core working for FreeBSD. I don't think it has any native components so the quickest way might just be to grab the Linux artifacts and crossgen them for FreeBSD. I'll get back to you on that.

Now that the coreclr, corefx and core-setup repos have had master archived, where are code changes being committed? I've built 3.0.1-servicing, 3.1.0-preview1 and 3.1.0-rtm but they don't include any of the changes that have been made over the last few months for FreeBSD.

To build the 3.1.0 SDK, I needed SDKs for 3.0.100 and 3.1.100-preview1. I'll take a look soon at the new runtime repo and .NET 5 requirements because the typical build requirement for each published build has been an SDK from another recent build. I don't want 5 to move on so far that it requires 5.0.0-preview1 to build 5.0.0-preview3 and no one knows how to build preview1.

I haven't checked, but does source-build include support for building .NET 5 or will that come later?

[am11]

As per the announcement, the branches are preserved with tags, e.g. https://github.com/dotnet/coreclr/tree/master/. The new development (post 3.1) is taking place in dotnet/runtime repo.

[am11]

I don't think it has any native components

Actually there are (at least?) two mutually exclusive native dependencies in ASP.NET: libuv, used by Kestrel and SQLitePCLRaw.bundle_e_sqlite3 used by EFCore. The former is available via FreeBSD Ports (pkg install libuv). Related issue for the latter: https://github.com/ericsink/SQLitePCL.raw/issues/176.

[wfurt]

the problem is that replacing native binaries is not sufficient and it only worked for new Linux distributions and architecture. But for example System.Diagnostic.Process (msbuild heavily needs) will try to get process list from /proc and /sys entries. What we need is instead is call to BSD interop code. Only way how to fix it is to also rebuild managed code and target FreeBSD so proper source code is pulled in for managed assemblies.

[wfurt]

to pick up fixes for 3.x we will need to keep them as patches to source-build, fork repo or keep them as patches applied independently. (like port code) For post 3.x life should be easier as everything runtime needs lives in single place. We should try to stabilize that and possibly build runtime separately from the rest. As far as I know SDK part does not have any direct platform dependencies and even Linux version should work with runtime.

For asp.net sockat backend is default AFAIK and libuv should not be necessary. As far as I know it is fallback for legacy reasons (like we used to have libcurl for HTTP)

[jasonpugsley]

@FeodorFitsner I won't have a chance to try rebuilding aspnet right now but see what you get from the crossgen'd linux files. Extract this archive into the same location as your dotnet binary, the contents end up in "shared" alongside "Microsoft.NETCore.App" aspnetcore-runtime-3.0.0-freebsd-x64.tar.gz

With a vanilla 3.0.0 SDK a simple test fails because System.IO.FileSystemWatcher isn't implemented on FreeBSD though @wfurt did submit a patch for that a while back.

See how you go.

[FeodorFitsner]

@jasonpugsley Looks like I lost the access to my FreeBSD instance after turning it off/on. I will probably start doing the whole exercise according the your guide. Just to clarify, I have to put aspnetcore-runtime-3.0.0-freebsd-x64.tar.gz into the same directory where I unpack produced dotnet-sdk-3.0.100-freebsd-x64.tar.gz?

[wfurt]

Microsoft.AspNetCore.App should be at same level as Microsoft.NETCore.App under dotnet/shared

[crummel]

cc @dseefeld for bootstrapping, I think we might be obsoleting buildbootstrapcli.sh soon.

[crummel]

Sorry, I was confused, that script is still valid for native bootstrapping. Dan's new scripts are for toolset bootstrapping so they don't apply here.

[wfurt]

I don't think Jail will work @am11. I did some experiments over the weekend and I get:

linux: pid 4425 (dotnet): syscall membarrier not implemented
pid 4425 (dotnet), jid 0, uid 0: exited on signal 11 (core dumped)

Documentation does mention that some beasts like systemd may not work. I think runtime is even worse as it depends on many special functions most user utilities do not need.

I was also thinking about the problem and I'm not aware of any good way how to create managed assemblies without having supported cli. However I did realized that I can spin up ad-hoc VM and treat is almost as "BSD only" as it does not depend on any external system to do the build. I started https://github.com/wfurt/freebsd-bootstrap-cli focused solely on creating bootstrap cli. It may be slow but if it is reliable and consistent it may serve the job. It is not quite complete but it has core parts - building on freebsd & creating VM where assemblies can be built. It would be great if people can take a look and contribute feedback or code updates. I looked at my old notes and things have changed. It seems like @jasonpugsley may have most recent experience. My goal would be to take his notes (or any other feedback) and turn them to scripts.

Discussion about bootstrap cli can move there and we can keep this thread only for issues with source-build it self.

[am11]

@wfurt, just a quick thought; .NET runtime is also compatible with OpenRC (init system for Alpine Linux), in addition to systemd. Maybe we can use Alpine (as it is super slim) in the jail, and we only need it for (AnyCPU) managed assemblies, so the flavor of libc difference does not affect us.

turn them to scripts.

this was exactly what i was thinking, 100% reproducible build on a public cloud is a far better investment compared to one-off, point in time, successful local build, which just works on my machine.

[trasz]

I don't think Jail will work @am11. I did some experiments over the weekend and I get:

linux: pid 4425 (dotnet): syscall membarrier not implemented
pid 4425 (dotnet), jid 0, uid 0: exited on signal 11 (core dumped)

FWIW, this should be quite trivial to implement. Are you running 13-CURRENT? Could you point me to the dotnet binary?

[wfurt]

I'm running on 12.1 (VM) but that is easy to fix. You can get https://download.visualstudio.microsoft.com/download/pr/d731f991-8e68-4c7c-8ea0-fad5605b077a/49497b5420eecbd905158d86d738af64/dotnet-sdk-3.1.100-linux-x64.tar.gz and run dotnet --info. However that may not be only one issue as the code depends on /proc and /sys entries and that seems to be incomplete. But if we could get enough working to build, it could be path forward.

[ghost]

Apologies for posting here, just couldn't see any other active FreeBSD discussion Do we know if .NET 5 will support FreeBSD or it's still yet to be decided?

[joperator]

@junglebus' question was asked more than a month ago and has still not been answered. It would be very nice to get some more information about the .NET Core roadmap for FreeBSD, including the initial support for FreeBSD in the Azure Pipelines Agent, to see if Microsoft and the .NET Platform teams are currently working on it, or if everyone who is interested in .NET Core for FreeBSD should contribute to the dotnet/runtime repo, which is now the current starting point for this, I think. I also noticed that the Workflow Guide already contains an entry for FreeBSD, but it's not mentioned elsewhere in the text. Maybe you could give some hint where to start there, because I think the build instructions in this thread are mostly outdated since the main dotnet repos have been moved to dotnet/runtime.

[danmoseley]

I do not believe there is a plan to support FreeBSD officially (ie., offer Microsoft support for it) but we do continue to want to support folks who are enthusiastic about working on it. @wfurt is our primary person here.

cc @jkotas

[jasonpugsley]

I thought I'd write to this thread as there's already a lot of potentially interested people on it and I haven't been able to find much discussion elsewhere.

As far as I know, FreeBSD is still not on the roadmap for 5.0. Regardless, @wfurt and others have been committing FreeBSD changes to dotnet/runtime and they've done a great job. I had to spend several weeks catching up and building many interim releases but I finally got Preview 1 & 2 built and now I have no issue getting the master branch to regularly build on FreeBSD. That's a huge leap forward and I can see a great deal of effort went in to get the branch to that state.

It looks like work is underway to cross-compile the SDK from Linux so that the FreeBSD build can be added to the devops pipeline for frequent automated builds. That's great as the configuration for the build of runtime and installer (was core-sdk) is frequently updated to use quite recent prior builds and packages. I've been lucky so far as there have only been a few times where the dependencies have actually required a newer build, but it does involve a lot of work each time. I'll be happy when the builds and packages start getting published again.

I spent this weekend getting an updated build of SDK 3.1.103 together. I did incorporate the libinotify fix as well as build ASP.NET this time. For a non-trivial test I installed https://piranhacms.org/docs/basics/project-templates (had to muck around to get libe_sqlite3.so compiled and working) and the web app seemed to work OK. If there are people that want 3.1.103 then let me know and I'll upload the files and create some basic install instructions. I'm not going to update the build instructions for 3 as it would be a lot of work to reproduce the steps from scratch for someone else to follow (and no, I'm not making a port). I doubt I'll spend any more time focusing on 3 now and instead concentrate on 5.

My reason for building 3.1.103 was to attempt to build the azure-pipelines-agent. It was kinda tricky but I managed to get version 2.166.2 to build. I have no idea how to configure/use it though :grin: so I don't know if it works. I think the Linux agent has official support, so the cross-compiled 5.0 SDK may be the way forward for now. Is it worth trying to get a FreeBSD agent functioning for this or any other use on Azure Pipelines?

Finally, can anyone tell me if there are discussions happening regarding FreeBSD & .NET 5.0 anywhere because I don't know what it would be useful to look at next.

[FeodorFitsner]

@jasonpugsley I'd love to play with SDK 3.1.103 (ironically for the same reason - running AppVeyor Build Agent on FreeBSD 😄) - could you share your build please. Thank you for your efforts!

[wfurt]

FreeBSD is now part of CI validation. Hopefully that will last longer than previous attempt. That however does not produce consumable packages as there is hesitancy to do official builds for unofficial platform. That may be fixed in reasonably near future as some alternative plans are being discussed.

I'm in process of updating build instructions. Same strategy we use in CI can be used to produce runtime (and possibly SKD) and either be used directly or used as bootstrap CLI in runtime repo on FreeBSD or for complete source-build.

I still think there is value in getting 3.1 builds as that is current LTS and it would be nice IMHO to get parity. @am11 did some work and had Cirus setup to do build: https://github.com/am11/freebsd-bootstrap-cli/releases/tag/v3.0.0. Maybe that can be extended to produce images unless somebody has better idea or build options.

As far as the agent, my original PR got closed recently after waiting more than year for review. If there is interest I think best next step is to establish fork and work there instead of trying to get fixes to the main tree. I'd be happy to help and contribute my past experience. From runtime repo perspective it is unlikely we would use FreeBSD agent (and build on FreeBSD) any time soon.

[wfurt]

You need to pick up build-rootfs.sh from https://raw.githubusercontent.com/dotnet/arcade/master/eng/common/cross/build-rootfs.sh as it did not bubble to runtime yet.

[wfurt]

or actually use the container what CI uses. Since that is now part of verification, we will need to keep up functional. If we can incorporate container, it would bring all other dependencies runtime has or may have in the future.

[wfurt]

That sounds good. I look at the outcome and it looks nice. We should perhaps move that discussion outside of source-build. We can return here if there is actual problem with source-build.

[jasonpugsley]

Just a quick update, you can download the 3.1.103 SDK The instructions need a bit more work but hopefully it's enough to start.

[jasonpugsley]

I haven't had much time this week but I did build 5.0 Preview 3 including ASP.NET. Files linked here.

[FeodorFitsner]

@jasonpugsley It works! 😃 Using your SDK 3.1 we've been able to build AppVeyor Build Agent to executables (yes, with -r freebsd-x64 option) without a single warning! And it works! I was able to hack a proof-of-concept FreeBSD 12.1 build image on GCP with that agent and run some builds: https://ci.appveyor.com/project/FeodorFitsner/freebsd-test/builds/32445332

The agent has quite a codebase: lots of deployment providers, internal Kestrel web server for API, it's communicating with AppVeyor via SignalR, etc. - I don't know yet which parts are not working, but essential functionality does: https://ci.appveyor.com/project/FeodorFitsner/freebsd-test/builds/32431289#L13

I'd love to capture your knowledge on how you do your builds and implement it in AppVeyor build, so we could always have a working SDK. We can use that image as a bootstrap. If you'd like to share your recipe I can sketch an appveyor.yml and we can continue working on that directly in some repo.

I'm so excited to work on that now as we have a working prototype of a real app! 🎉

[jasonpugsley]

@FeodorFitsner I finally went through the steps again and documented them Build .NET SDK 3.1.103 for FreeBSD Good luck!