Source-build: Building the .NET Core SDK on FreeBSD

Created on 15 Jul 2019  ·  186Comments  ·  Source: dotnet/source-build

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?

up-for-grabs
Source
picture joperator
👍6

Most helpful comment

[furt@daemon /mnt/github/source-build]$ time ./build.sh
...
...
...
ls-local/prebuilt-baseline-online.xml' [/mnt/github/source-build/repos/known-good.proj]
    2701 Warning(s)
    0 Error(s)

Time Elapsed 00:59:53.44

real    59m54.934s
user    52m7.936s
sys 21m48.115s    2701 Warning(s)
    0 Error(s)

I can finally build everything. I did hit some weird issues while trying to build various repos.
It turned out I was running of out memory and 4G is not enough. After moving to 8G in my VM build is more stable even if it still aborts randomly once in a while.

picture wfurt on 15 Nov 2019
👍5 🎉2

All 186 comments

even source-build needs working SDK and that is problematic since lost build servers. I was planning to revisit the effort but closing on 3.0 prevented me from spending any reasonable time on it.

Aside from that, more cleanup may be needed to deal with OS differences.

wfurt picture wfurt on 15 Jul 2019
👍1

I've already tried to use the old (December 2018) but working .NET Core SDK for FreeBSD as bootstrap CLI as described here. But when running ./init-tools.sh it produces the same output as above and doesn't finish even after several hours.

I could spend some time trying to re-enable .NET Core for FreeBSD, but I need to know where to start because the current documentations don't help me much if they don't work. For example, it would be helpful to know why the build servers were lost and how the .NET Core SDK for FreeBSD that I mentioned was created at that time.

joperator picture joperator on 15 Jul 2019
👍1

That is something source-build gurus should comment on. Published SDK was built by bootstrapping each needed repo separately and by publishing and consuming intermediate packages. As more repos moved to Arcade, lot of the build process was in flux. I would not be surprised in documentation or code is out of sync.

wfurt picture wfurt on 15 Jul 2019

We've changed our process so that repos are cloned as part of the build process to ./bin/src. This lets us piggyback off other .NET infrastructure to keep source-build up to date more easily. netcorecli-fsc and reference-assemblies are both fake repos that live in source-build, so it's expected you'll have those in ./src. Your error from ./build.sh looks like init-tools is failing - could you post your init-tools.log from the root of the repo?

crummel picture crummel on 15 Jul 2019
👍1

Yes, init-tools is indeed failing. The first error was a problem with the SSL certificate while restoring NuGet packages. I could fix it by setting the SSL_CERT_FILE environment variable to /usr/local/share/certs/ca-root-nss.crt as described here. But now there seems to be another problem with the SSL connection:
init-tools.log
The SSL certificate from https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json exists in my ca-root-nss.crt file. So I'm surprised that NuGet package restore still seems to have problems establishing an SSL connection.

joperator picture joperator on 16 Jul 2019
👍1

It looks like dotnet has problems with the linux-c7-openssl-libs package. I installed it on my FreeBSD machine to ensure full Linux binary compatibility, because the first time I ran ./build.sh I got
No usable version of libssl was found.

After removing this package, reinstalling the default OpenSSL package for FreeBSD, and creating the required symbolic links, running ./init-tools.sh using the .NET Core SDK for FreeBSD as bootstrap CLI succeeded.
I can now tell build.sh to use .NET Core SDK version 3.0.100-preview-010021 via editing DotnetCLIVersion.txt, but running it still fails:
error.txt

joperator picture joperator on 16 Jul 2019
👍1

Ah, that looks like Darc (the tool we use to clone the source) doesn't build for BSD. I wonder if we can build that portable, I will take a look. Otherwise this is probably a fix in dotnet/arcade-services.

crummel picture crummel on 17 Jul 2019

I was able to build Darc on FreeBSD using target framework netcoreapp3.0 instead of netcoreapp2.1. Cloning the repos now seems to work, but building them still fails. I have run ./build.sh and received the following output:
arcade-error.txt
arcade-build.binlog.txt
arcade.log

I also ran ./build.sh /p:RootRepo=core-setup and received the following output:
core-setup-error.txt
core-setup-build.binlog.txt
linker.log

So in both cases I get the error Segmentation fault (core dumped).
I also receive linux: pid 1234 (dotnet): syscall membarrier not implemented in the terminal, which is not logged into the files.

joperator picture joperator on 18 Jul 2019
👍1

I've seen similar errors with missing syscalls on ARM. At this point it's probably less of a source-build problem and more getting into bootstrapping the actual SDK on BSD - there's a couple related issues: https://github.com/dotnet/core-setup/issues/5083, https://github.com/dotnet/core-sdk/issues/248, https://github.com/dotnet/source-build/issues/724.

crummel picture crummel on 18 Jul 2019
👍1

Looks like it is a bootstrapping problem, but probably not as you expected @crummel: Although I specified to use the .NET Core SDK for FreeBSD as bootstrap CLI, the build scripts also downloaded the .NET Core SDK 3.0.100-preview5-011568 for Linux and placed it in the source-build/Tools/dotnetcli3 folder. After replacing the folder with source-build/Tools/dotnetcli, which contains the .NET Core SDK for FreeBSD, the build continues.
Now it tries to build Microsoft.DotNet.Arcade.csproj, but fails with error CS1617: Invalid option 'preview' for /langversion. Use '/langversion:?' to list supported values.

joperator picture joperator on 30 Jul 2019

Replacing <langversion>preview</langversion> with <langversion>latest</langversion> in Microsoft.DotNet.Arcade.csproj fixes the above error. It looks like I'm now able to build the main parts of the .NET Core SDK on FreeBSD. I only get the following two errors after the build succeeded:

'common' failed during build.
See '/root/git/dotnet/source-build/bin/logs/common.log' for more information.
'known-good' failed during build.

I've already taken a look at the common.log, but there's nothing there that indicates an error.
So does anyone know what's common and known-good? Are they required for the .NET Core SDK? And where is the .NET Core SDK stored after the build is complete? Or do I have to copy and paste the parts manually?
Any help would be appreciated. Thanks in advance.

joperator picture joperator on 31 Jul 2019
👍1

AFAIK known-good is the set of components that need to be built to assemble .NET Core itself. Right now, it's roughly analogous to the all target in other projects' makefiles.

If everything (including the cli) built succefully, the result should be a bin/x64/Release/dotnet-sdk-*tar.gz file. That's the .NET Core SDK itself. For fedora that's pretty much all we need. We extract it to /usr/lib64/dotnet.

omajid picture omajid on 31 Jul 2019

That is great progress @joperator. Do you have any outstanding changes or just something you need to set?
With 3.0 under control now, I should have some cycles again to give FreeBSD another try.
Just to confirm: You use FreeBSD bootstrap cli, not Linux under emulation, right?

wfurt picture wfurt on 31 Jul 2019
👍1

@omajid: Then it looks like I have to build known-good as well because my bin/x64/Release folder only contains an empty netcorecli-fsc directory.

@wfurt: There are outstanding changes as well as some things you need to set to successfully run build.sh on FreeBSD. But these changes are only limited to a few files, where some of them are already described above. I will soon provide a complete list of these necessary changes.
I'm using FreeBSD bootstrap CLI to build the .NET projects. While running build.sh it downloaded and tried to use the .NET Core SDK for Linux. But that didn't work, as I described above.

joperator picture joperator on 1 Aug 2019
👍1

Very good @joperator. I'm hoping to get newer version of the SDK published (closer to 3.0 final content) but I could not build some components again. If you get build working it would help me with that effort.

As far as the Linux SDK: I made changes in several components to recognize FreeBSD properly. I was on Linux path for a while until I realized that is dead-end path. Even if the binaries work under emulation it still uses many files from /proc and that will not work on FreeBSD. Getting source build working is best long-term option for FreeBSD. I would still like to build components using published sdk to avoid regressions.

wfurt picture wfurt on 1 Aug 2019
👍1

I agree with you @wfurt:

Getting source build working is best long-term option for FreeBSD.

Therefore, here is a complete list of the necessary settings and changes to build the source-build repo on FreeBSD.
I have built it using the current master (Aug 2, 2019) of the source-build repo and a VM with FreeBSD 12.0-RELEASE amd64 on a Windows 10 host.

Install and configure required packages

Install git

pkg install git

Install libunwind

pkg install libunwind

Install and configure bash (Building-.NET-Core-3.x-on-FreeBSD)

pkg install bash
ln -s /usr/local/bin/bash /bin/bash

Install and configure OpenSSL (dotnet/coreclr#22124)

pkg install openssl
ln -s /usr/local/lib/libssl.so.9 /usr/local/lib/libssl.so.8
ln -s /usr/local/lib/libcrypto.so.9 /usr/local/lib/libcrypto.so.8

Clone the source-build repo

git clone https://github.com/dotnet/source-build.git ~/git/dotnet/source-build

Set your environment variables

Prevent the dotnet CLI from freezing with no output (dotnet/coreclr#22124)

setenv LD_PRELOAD /usr/lib/libpthread.so

Set the path of the bootstrap CLI (Use the bootstrap CLI to build source-build). I have used dotnet-sdk-latest-freebsd-x64.tar.gz as bootstrap CLI.

setenv DotNetBootstrapCliTarPath $(DotNetBootstrapCliTarDir)/dotnet.tar

Build the source-build repo

cd ~/git/dotnet/source-build

./init-tools.sh
  ...
  Initializing BuildTools...
  ...
  Done initializing BuildTools.
  Initializing Arcade...
  Done initializing Arcade.
  Done initializing tools.

./build.sh
  ...
  warning: submodules tools-local/arcade-services does not appear to be initialized.
  Should I initialize it for you? [Y]es / [n]o / [a]ll / [q]uit] y
  ...
  Tools are already initialized
  ...
  No executable found matching command "dotnet-/root/git/dotnet/source-build/Tools/dotnetcli/sdk/2.2.300/MSBuild.dll". See https://aka.ms/missing-command for more information.

Fix dotnet CLI version

ee DotnetCLIVersion.txt

Replace 2.2.300 with 3.0.100-preview-010021.

Replace the downloaded dotnet CLI for Linux with the bootstrap CLI for FreeBSD

rm -r Tools/dotnetcli3
cp -r Tools/dotnetcli Tools/dotnetcli3

./build.sh
  ...
  /root/git/dotnet/source-build/tools-local/init-build.proj(153,5): error MSB3073: The command "/root/git/dotnet/source-build/Tools/dotnetcli/dotnet build -c Release /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Microsoft.DotNet.Darc.csproj" exited with code 1.

Change target framework netcoreapp2.1 to netcoreapp3.0 and commit your changes

cd tools-local/arcade-services
ee src/Microsoft.DotNet.Darc/src/Darc/Microsoft.DotNet.Darc.csproj

Replace <TargetFramework>netcoreapp2.1</TargetFramework> with <TargetFramework>netcoreapp3.0</TargetFramework>.

git commit -a -m "Change target framework of 'Microsoft.DotNet.Darc.csproj' from 'netcoreapp2.1' to 'netcoreapp3.0'."
cd ../..
git add tools-local/arcade-services
git commit -m "Update submodule 'tools-local/arcade-services'."

./build.sh
  ...
  No executable found matching command "dotnet-/root/git/dotnet/source-build/tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1/Microsoft.DotNet.Darc.dll". See https://aka.ms/missing-command for more information.
  /root/git/dotnet/source-build/tools-local/init-build.proj(180,5): error MSB3073: The command "/root/git/dotnet/source-build/Tools/dotnetcli/dotnet /root/git/dotnet/source-build/tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1/Microsoft.DotNet.Darc.dll clone --repos-folder /root/git/dotnet/source-build/bin/src/ --git-dir-folder /root/git/dotnet/source-build/.git/modules/src/ --include-toolset --ignore-repos ";https://dev.azure.com/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/devdiv/DevDiv/_git/DotNet-Trusted;https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Trusted;https://[email protected]/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/dnceng/internal/_git/dotnet-core-setup" --azdev-pat bogus --github-pat bogus --depth 0 --debug" exited with code 1.

Copy the binaries to the expected directory because we changed the target framework from netcoreapp2.1 to netcoreapp3.0

rm -r tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1
cp -r tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp3.0 tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1

./build.sh
  ...
          Something failed while cloning.
    System.Exception: Something went wrong when cloning repo https://github.com/dotnet/arcade at <default branch> into /root/git/dotnet/source-build/bin/src/arcade ---> System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'git2-572e4d8' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Shared object "libgit2-572e4d8" not found, required by "dotnet"
       at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
       at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary()
       at LibGit2Sharp.Core.NativeMethods..cctor()
       --- End of inner exception stack trace ---
       at LibGit2Sharp.Core.NativeMethods.git_clone(git_repository*& repo, String origin_url, FilePath workdir_path, GitCloneOptions& opts)
       at LibGit2Sharp.Core.Proxy.git_clone(String url, String workdir, GitCloneOptions& opts)
       at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, CloneOptions options)
       at Microsoft.DotNet.DarcLib.RemoteRepoBase.Clone(String repoUri, String commit, String targetDirectory, ILogger _logger, String pat, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 176
       --- End of inner exception stack trace ---
       at Microsoft.DotNet.DarcLib.RemoteRepoBase.Clone(String repoUri, String commit, String targetDirectory, ILogger _logger, String pat, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 210
       at Microsoft.DotNet.DarcLib.GitHubClient.Clone(String repoUri, String commit, String targetDirectory, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/GitHubClient.cs:line 875
       at Microsoft.DotNet.DarcLib.Remote.Clone(String repoUri, String commit, String targetDirectory, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Actions/Remote.cs:line 983
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopyAndCreateGitDir(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, String gitDirRedirect, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 284
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopyWithGitDirPath(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 272
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopy(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 225
       at Microsoft.DotNet.Darc.Operations.CloneOperation.ExecuteAsync() in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 102
  /root/git/dotnet/source-build/tools-local/init-build.proj(180,5): error MSB3073: The command "/root/git/dotnet/source-build/Tools/dotnetcli/dotnet /root/git/dotnet/source-build/tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1/Microsoft.DotNet.Darc.dll clone --repos-folder /root/git/dotnet/source-build/bin/src/ --git-dir-folder /root/git/dotnet/source-build/.git/modules/src/ --include-toolset --ignore-repos ";https://dev.azure.com/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/devdiv/DevDiv/_git/DotNet-Trusted;https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Trusted;https://[email protected]/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/dnceng/internal/_git/dotnet-core-setup" --azdev-pat bogus --github-pat bogus --depth 0 --debug" exited with code 42.

Install missing libraries for LibGit2Sharp

pkg install libgit2
ln -s /usr/local/lib/libgit2.so /usr/local/lib/libgit2-572e4d8.so

./build.sh
  ...
          Something failed while cloning.
    System.Exception: Something went wrong when cloning repo https://github.com/mono/linker.git at refs/heads/master into /root/git/dotnet/source-build/bin/src/linker ---> LibGit2Sharp.LibGit2SharpException: failed to connect to github.com: Operation timed out
       at LibGit2Sharp.Core.Ensure.HandleError(Int32 result)
       at LibGit2Sharp.Core.Proxy.git_submodule_update(SubmoduleHandle submodule, Boolean init, GitSubmoduleUpdateOptions& options)
       at LibGit2Sharp.SubmoduleCollection.Update(String name, SubmoduleUpdateOptions options)
       at Microsoft.DotNet.DarcLib.RemoteRepoBase.CheckoutSubmodules(Repository repo, CloneOptions submoduleCloneOptions, String gitDirParentPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 222
       at Microsoft.DotNet.DarcLib.RemoteRepoBase.Clone(String repoUri, String commit, String targetDirectory, ILogger _logger, String pat, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 205
       --- End of inner exception stack trace ---
       at Microsoft.DotNet.DarcLib.RemoteRepoBase.Clone(String repoUri, String commit, String targetDirectory, ILogger _logger, String pat, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 210
       at Microsoft.DotNet.DarcLib.GitHubClient.Clone(String repoUri, String commit, String targetDirectory, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/GitHubClient.cs:line 875
       at Microsoft.DotNet.DarcLib.Remote.Clone(String repoUri, String commit, String targetDirectory, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Actions/Remote.cs:line 983
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopyAndCreateGitDir(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, String gitDirRedirect, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 284
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopyWithGitDirPath(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 272
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleMasterCopy(RemoteFactory remoteFactory, String repoUrl, String masterGitRepoPath, String masterRepoGitDirPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 225
       at Microsoft.DotNet.Darc.Operations.CloneOperation.ExecuteAsync() in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 102
  /root/git/dotnet/source-build/tools-local/init-build.proj(180,5): error MSB3073: The command "/root/git/dotnet/source-build/Tools/dotnetcli/dotnet /root/git/dotnet/source-build/tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1/Microsoft.DotNet.Darc.dll clone --repos-folder /root/git/dotnet/source-build/bin/src/ --git-dir-folder /root/git/dotnet/source-build/.git/modules/src/ --include-toolset --ignore-repos ";https://dev.azure.com/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/devdiv/DevDiv/_git/DotNet-Trusted;https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Trusted;https://[email protected]/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/dnceng/internal/_git/dotnet-core-setup" --azdev-pat bogus --github-pat bogus --depth 0 --debug" exited with code 42.

./build.sh
  ...
          Something failed while cloning.
    System.Exception: Something went wrong when checking out $(GitCommitHash) in /root/git/dotnet/source-build/bin/src/linker.$(GitCommitHash) ---> System.InvalidOperationException: Sequence contains no matching element
       at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source, Func`2 predicate)
       at Microsoft.DotNet.DarcLib.LocalGitClient.CleanRepoAndSubmodules(Repository repo, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/LocalGitClient.cs:line 427
       at Microsoft.DotNet.DarcLib.LocalGitClient.Checkout(String repoDir, String commit, Boolean force) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/LocalGitClient.cs:line 308
       --- End of inner exception stack trace ---
       at Microsoft.DotNet.DarcLib.LocalGitClient.Checkout(String repoDir, String commit, Boolean force) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/LocalGitClient.cs:line 347
       at Microsoft.DotNet.DarcLib.Local.Checkout(String commit, Boolean force) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Actions/Local.cs:line 144
       at Microsoft.DotNet.Darc.Operations.CloneOperation.HandleRepoAtSpecificHash(String repoPath, String commit, String masterRepoGitDirPath, ILogger log) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 218
       at Microsoft.DotNet.Darc.Operations.CloneOperation.ExecuteAsync() in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/CloneOperation.cs:line 106
  /root/git/dotnet/source-build/tools-local/init-build.proj(180,5): error MSB3073: The command "/root/git/dotnet/source-build/Tools/dotnetcli/dotnet /root/git/dotnet/source-build/tools-local/arcade-services/artifacts/bin/Microsoft.DotNet.Darc/Release/netcoreapp2.1/Microsoft.DotNet.Darc.dll clone --repos-folder /root/git/dotnet/source-build/bin/src/ --git-dir-folder /root/git/dotnet/source-build/.git/modules/src/ --include-toolset --ignore-repos ";https://dev.azure.com/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/devdiv/DevDiv/_git/DotNet-Trusted;https://devdiv.visualstudio.com/DevDiv/_git/DotNet-Trusted;https://[email protected]/dnceng/internal/_git/dotnet-optimization;https://dev.azure.com/dnceng/internal/_git/dotnet-core-setup" --azdev-pat bogus --github-pat bogus --depth 0 --debug" exited with code 42.

Clone jbevain/cecil to the expected directory

rm -r bin/src/linker.$(GitCommitHash)/external/cecil
git clone https://github.com/jbevain/cecil.git bin/src/linker.$(GitCommitHash)/external/cecil

./build.sh
  ...
  /root/git/dotnet/source-build/repos/dir.targets(281,5): error MSB3073: The command "/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/build.sh  --pack --configuration Release --binaryLog  /p:DotNetPackageVersionPropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/PackageVersions.props /p:DotNetRestoreSourcePropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/RestoreSources.props >> /root/git/dotnet/source-build/bin/logs/sourcelink.log 2>&1" exited with code 145. [/root/git/dotnet/source-build/repos/sourcelink.proj]
    Found dotnet SDK, but did not find dotnet.dll at [/root/git/dotnet/source-build/Tools/dotnetcli3/sdk/3.0.100-preview6-012264/dotnet.dll]
    Build failed (exit code '145').

    'sourcelink' failed during build.
    See '/root/git/dotnet/source-build/bin/logs/sourcelink.log' for more information.
    'known-good' failed during build.

Copy the dotnet SDK to the expected directory because we replaced the dotnet CLI for Linux with the bootstrap CLI for FreeBSD

cp -r Tools/dotnetcli3/sdk/3.0.100-preview-010021/* Tools/dotnetcli3/sdk/3.0.100-preview6-012264

./build.sh
  ...
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.GitHub/Microsoft.SourceLink.GitHub.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Common/Microsoft.SourceLink.Common.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Vsts.Git/Microsoft.SourceLink.Vsts.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/Microsoft.Build.Tasks.Git/Microsoft.Build.Tasks.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.GitHub/Microsoft.SourceLink.GitHub.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Common/Microsoft.SourceLink.Common.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/Microsoft.Build.Tasks.Git/Microsoft.Build.Tasks.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Vsts.Git/Microsoft.SourceLink.Vsts.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Vsts.Tfvc/Microsoft.SourceLink.Vsts.Tfvc.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.GitLab/Microsoft.SourceLink.GitLab.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Vsts.Tfvc/Microsoft.SourceLink.Vsts.Tfvc.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Bitbucket.Git/Microsoft.SourceLink.Bitbucket.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.GitLab/Microsoft.SourceLink.GitLab.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Tfs.Git/Microsoft.SourceLink.Tfs.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Bitbucket.Git/Microsoft.SourceLink.Bitbucket.Git.csproj]
    CSC : error CS1617: Invalid option 'Preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/sourcelink.$(GitCommitHash)/src/SourceLink.Tfs.Git/Microsoft.SourceLink.Tfs.Git.csproj]
        0 Warning(s)
        16 Error(s)

    Time Elapsed 00:00:14.68
    Build failed (exit code '1').

    'sourcelink' failed during build.
    See '/root/git/dotnet/source-build/bin/logs/sourcelink.log' for more information.
    'known-good' failed during build.

Replace language version Preview with 8.0

ee bin/src/sourcelink.$(GitCommitHash)/src/Directory.Build.props

Replace <LangVersion>Preview</LangVersion> with <LangVersion>8.0</LangVersion>.

Remove modifier readonly from properties because it is not valid for these items

ee bin/src/sourcelink.$(GitCommitHash)/src/Microsoft.Build.Tasks.Git/GitDataReader/GitRepositoryLocation.cs

Remove modifier readonly from properties.

./build.sh
  ...
    CSC : error CS1617: Invalid option 'preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/src/Microsoft.DotNet.Arcade.Sdk/Microsoft.DotNet.Arcade.Sdk.csproj]
      Microsoft.DotNet.SignTool -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.SignTool/Release/netcoreapp2.0/Microsoft.DotNet.SignTool.dll
      Microsoft.DotNet.Deployment.Tasks.Links -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Deployment.Tasks.Links/Release/net472/Microsoft.DotNet.Deployment.Tasks.Links.dll
      Microsoft.DotNet.Deployment.Tasks.Links -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Deployment.Tasks.Links/Release/netcoreapp2.0/Microsoft.DotNet.Deployment.Tasks.Links.dll
      Microsoft.DotNet.GenFacades -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.GenFacades/Release/net472/Microsoft.DotNet.GenFacades.dll
    CSC : error CS1617: Invalid option 'preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/src/Microsoft.DotNet.Arcade.Sdk/Microsoft.DotNet.Arcade.Sdk.csproj]
      Microsoft.DotNet.GenFacades -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.GenFacades/Release/netcoreapp2.1/Microsoft.DotNet.GenFacades.dll
      Microsoft.DotNet.CoreFxTesting -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.CoreFxTesting/Release/netcoreapp2.1/Microsoft.DotNet.CoreFxTesting.dll
      Microsoft.DotNet.CoreFxTesting -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.CoreFxTesting/Release/net472/Microsoft.DotNet.CoreFxTesting.dll
      Microsoft.DotNet.Build.Tasks.Packaging -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Build.Tasks.Packaging/Release/net472/Microsoft.DotNet.Build.Tasks.Packaging.dll
      Microsoft.DotNet.Build.Tasks.Packaging -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Build.Tasks.Packaging/Release/netcoreapp2.1/Microsoft.DotNet.Build.Tasks.Packaging.dll
      Microsoft.DotNet.Build.Tasks.Configuration -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Build.Tasks.Configuration/Release/netcoreapp2.1/Microsoft.DotNet.Build.Tasks.Configuration.dll
      Microsoft.DotNet.Build.Tasks.Configuration -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.Build.Tasks.Configuration/Release/net472/Microsoft.DotNet.Build.Tasks.Configuration.dll
      Microsoft.DotNet.CodeAnalysis -> /root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/artifacts/bin/Microsoft.DotNet.CodeAnalysis/Release/netstandard2.0/Microsoft.DotNet.CodeAnalysis.dll

    Build FAILED.

    CSC : error CS1617: Invalid option 'preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/src/Microsoft.DotNet.Arcade.Sdk/Microsoft.DotNet.Arcade.Sdk.csproj]
    CSC : error CS1617: Invalid option 'preview' for /langversion. Use '/langversion:?' to list supported values. [/root/git/dotnet/source-build/bin/src/arcade.$(GitCommitHash)/src/Microsoft.DotNet.Arcade.Sdk/Microsoft.DotNet.Arcade.Sdk.csproj]
        0 Warning(s)
        2 Error(s)

    Time Elapsed 00:00:24.02
    Build failed (exit code '1').

    'arcade' failed during build.
    See '/root/git/dotnet/source-build/bin/logs/arcade.log' for more information.
    'known-good' failed during build.

Replace language version preview with latest

ee bin/src/arcade.$(GitCommitHash)/src/Microsoft.DotNet.Arcade.Sdk/Microsoft.DotNet.Arcade.Sdk.csproj

Replace <LangVersion>preview</LangVersion> with <LangVersion>latest</LangVersion>.

Fix false positives

If you get messages like

/root/git/dotnet/source-build/repos/dir.targets(378,5): error : $(Repo) produced no new source-built package identities. Known possible causes: [/root/git/dotnet/source-build/repos/$(Repo).proj]
/root/git/dotnet/source-build/repos/dir.targets(378,5): error : ^ There may have been a silent failure in the submodule build. To confirm, check the build log file for undetected errors that may have prevented package creation: /root/git/dotnet/source-build/bin/logs/$(Repo).log [/root/git/dotnet/source-build/repos/$(Repo).proj]
/root/git/dotnet/source-build/repos/dir.targets(378,5): error : ^ This error might be a false positive if $(Repo) intentionally builds no nuget packages. If so, set the SkipEnsurePackagesCreated property to true in /root/git/dotnet/source-build/repos/$(Repo).proj [/root/git/dotnet/source-build/repos/$(Repo).proj]
/root/git/dotnet/source-build/repos/dir.targets(378,5): error : ^ The 'bin' directory might be dirty from a previous build and the package files already existed. If so, perform a clean build, or check which packages were already in 'bin' by opening /root/git/dotnet/source-build/bin/obj/x64/Release/PackageVersions.props.pre.$(Repo).xml [/root/git/dotnet/source-build/repos/$(Repo).proj]
/root/git/dotnet/source-build/repos/dir.targets(378,5): error : ^ The packages may have been written to an unexpected directory. For example, some repos used bin/ and changed to artifacts/ to match Arcade. Check PackagesOutput in /root/git/dotnet/source-build/repos/$(Repo).proj (currently '/root/git/dotnet/source-build/bin/src/$(Repo).$(GitCommitHash)/artifacts/packages/Release/NonShipping/') [/root/git/dotnet/source-build/repos/$(Repo).proj]

then make sure that there has not been a silent failure in the submodule builds, set the SkipEnsurePackagesCreated property as described and run ./build.sh again.

Fix missing app host freebsd-x64

If you get a message like

/root/git/dotnet/source-build/Tools/dotnetcli/sdk/3.0.100-preview-010021/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(220,5): error NETSDK1065: Cannot find app host for freebsd-x64. freebsd-x64 could be an invalid runtime identifier (RID). For more information about RID, see https://aka.ms/rid-catalog.

then just run ./build.sh again and the error will suddenly disappear.

Build completed successfully

After the build completed you should see the following output:

Executing: dotnet pack
  Successfully created package '/root/git/dotnet/source-build/bin/src/common.$(GitCommitHash)/artifacts/build/Microsoft.Extensions.CommandLineUtils.1.0.1.nupkg'.
Skipping tests because -NoTest was specified

Done


'common' failed during build.
See 'root/git/dotnet/source-build/bin/logs/common.log' for more information.
'known-good' failed during build.

A look at bin/logs/common.log indicates that common does not fail during build.
If known-good is necessary to assemble the .NET Core SDK itself as described above, it looks like it really fails during build, because my bin/x64/Release folder only contains an empty netcorecli-fsc directory. It would be great if someone could figure out why known-good fails during build, because there is neither an error in the terminal nor a log file.

joperator picture joperator on 2 Aug 2019
👍2 👀1

Known-good will fail if anything before it does, so that's probably what's happening. Could I get your whole bin/logs directory? And any *.binlog files under the repo root would be helpful, they get scattered in the individual bin/src directories.

crummel picture crummel on 2 Aug 2019

Yes, of course. Here are the logs from the bin/logs directory:
logs.zip

I had to split the *.binlog files into several zip archives so that each of them is smaller than the 10MB upload limit. The attached *.binlog files were located in these directories:

~/git/dotnet/source-build/src/netcorecli-fsc/msbuild.binlog
~/git/dotnet/source-build/build.binlog
~/git/dotnet/source-build/bin/src/arcade.8f3c22397990aeb20a88690b51dad4b33f21e7ff/artifacts/log/Release/ToolsetRestore.binlog
~/git/dotnet/source-build/bin/src/arcade.8f3c22397990aeb20a88690b51dad4b33f21e7ff/artifacts/log/Release/Build.binlog
~/git/dotnet/source-build/bin/src/sourcelink.51310e65e75010467993f793e1739d1a1dad50c5/artifacts/log/Release/ToolsetRestore.binlog
~/git/dotnet/source-build/bin/src/sourcelink.51310e65e75010467993f793e1739d1a1dad50c5/artifacts/log/Release/Build.binlog
~/git/dotnet/source-build/bin/src/xdt.c01a538851a8ab1a1fbeb2e6243f391fff7587b4/artifacts/log/Release/Build.binlog
~/git/dotnet/source-build/bin/src/standard.a9422da6ed91b413019ef93051613c5f03801d64/artifacts/log/Release/Build.binlog
~/git/dotnet/source-build/bin/src/roslyn.c91adff42c488aef2c2c532a7b053fb55e0c16ea/SourceBuild.binlog
~/git/dotnet/source-build/bin/src/roslyn.c91adff42c488aef2c2c532a7b053fb55e0c16ea/Microsoft.NETCore.Compilers.Package.binlog
~/git/dotnet/source-build/bin/src/cliCommandLineParser.0e89c2116ad28e404ba56c14d1c3f938caa25a01/artifacts/log/Release/Build.binlog
~/git/dotnet/source-build/bin/src/ApplicationInsights-dotnet.53b80940842204f78708a538628288ff5d741a1d/restore.binlog
~/git/dotnet/source-build/bin/src/ApplicationInsights-dotnet.53b80940842204f78708a538628288ff5d741a1d/build.binlog
~/git/dotnet/source-build/bin/src/ApplicationInsights-dotnet.53b80940842204f78708a538628288ff5d741a1d/pack.binlog
~/git/dotnet/source-build/bin/src/xliff-tasks.173ee3bd61c9549557eefa3cfb718bdef157cb87/msbuild.binlog
~/git/dotnet/source-build/bin/src/Newtonsoft.Json.cac0690ad133c5e166ce5642dc71175791404fad/restore.binlog
~/git/dotnet/source-build/bin/src/Newtonsoft.Json.cac0690ad133c5e166ce5642dc71175791404fad/build.binlog
~/git/dotnet/source-build/bin/src/Newtonsoft.Json.cac0690ad133c5e166ce5642dc71175791404fad/pack.binlog

And here are the attached *.binlog files:
netcorecli-fsc.zip
source-build.zip
arcade.8f3c22397990aeb20a88690b51dad4b33f21e7ff.zip
sourcelink.51310e65e75010467993f793e1739d1a1dad50c5.zip
xdt.c01a538851a8ab1a1fbeb2e6243f391fff7587b4.zip
standard.a9422da6ed91b413019ef93051613c5f03801d64.zip
roslyn.c91adff42c488aef2c2c532a7b053fb55e0c16ea.zip
cliCommandLineParser.0e89c2116ad28e404ba56c14d1c3f938caa25a01.zip
ApplicationInsights-dotnet.53b80940842204f78708a538628288ff5d741a1d.zip
xliff-tasks.173ee3bd61c9549557eefa3cfb718bdef157cb87.zip
Newtonsoft.Json.cac0690ad133c5e166ce5642dc71175791404fad.zip

joperator picture joperator on 5 Aug 2019

It looks like Roslyn is failing, possibly silently if you're not seeing it:
error NETSDK1065: Cannot find app host for freebsd-x64. freebsd-x64 could be an invalid runtime identifier (RID). We don't have a declared dependency from common on Roslyn, so I'm not sure why that's coming up as the source repo, but I think it might have to do with rebuilding - incremental builds don't work very well for us right now (which is also why you're getting the no packages produced false positives), so we recommend doing a git clean -fxd between builds. I'm not sure if the RID error means we need to patch it in somewhere or if we're not picking up the BSD runtime correctly - any ideas @wfurt?

crummel picture crummel on 5 Aug 2019
👍1

We did not build Roslyn in official builds as that is same on all platforms and comes in from NuGet package. We will probably need to submit fixes there to recognize FreeBSD as platform.

BTW is there option @crummel to build just runtime instead of whole SDK? I know we want SDK eventually but getting at least runtime would be good milestone.

wfurt picture wfurt on 6 Aug 2019
👍1

I can build SourceBuild.sln from the dotnet/roslyn repo after applying the following patches:

  • In roslyn/eng/targets/Settings.props add netcoreapp3.0 to the RoslynPortableTargetFrameworks property and freebsd-x64 to the RoslynPortableRuntimeIdentifiers property.
  • In roslyn/src/Compilers/Core/MSBuildTask/Microsoft.BuildTasks.CodeAnalysis.csproj replace
<PackageReference Include="System.IO.Pipes.AccessControl" Version="$(SystemIOPipesAccessControlVersion)" Condition="'$(TargetFramework)' == 'netcoreapp2.1'" />

  with

<PackageReference Include="System.IO.Pipes.AccessControl" Version="$(SystemIOPipesAccessControlVersion)" Condition="'$(TargetFramework)' == 'netcoreapp2.1' Or '$(TargetFramework)' == 'netcoreapp3.0'" />
  • In roslyn/src/Compilers/VisualBasic/Test/Emit/Microsoft.CodeAnalysis.VisualBasic.Emit.UnitTests.vbproj add
<DefineConstants Condition="'$(TargetFramework)' == 'netcoreapp3.0'">$(FinalDefineConstants),NETCOREAPP3_0=-1</DefineConstants>
  • In the *.cs files adjust the preprocessor directives containing NETCOREAPP2_1. For example:

    • Change #if NET472 || NETCOREAPP2_1 to #if NET472 || NETCOREAPP2_1 || NETCOREAPP3_0

    • Change #if !NETCOREAPP2_1 to #if !NETCOREAPP2_1 && !NETCOREAPP3_0

./build.sh from dotnet/source-build tries to build the Roslyn projects the same way, but as you've already mentioned @crummel, the incremental builds don't work very well and don't allow me to build the patched Roslyn projects, because after ./build.sh has cloned and failed to build the dotnet/roslyn repo, it won't try to rebuild the repo again when running ./build.sh the next time. The easiest way to fix building the Roslyn projects on FreeBSD, would be to send the above patches to dotnet/roslyn, I think.

joperator picture joperator on 6 Aug 2019

that would make sense. Why don't you create PR @joperator and mention me as well. Master branches should be now open for 5.0 work.

wfurt picture wfurt on 6 Aug 2019

BTW is there option @crummel Chris Rummel FTE to build just runtime instead of whole SDK?

We can add /p:RootRepo=core-setup to the ./build.sh command, but this will still build Roslyn because the CoreFX build requires a more recent C# compiler than is in the preview6 SDK, as well as to support coherency.

crummel picture crummel on 6 Aug 2019

after ./build.sh has cloned and failed to build the dotnet/roslyn repo, it won't try to rebuild the repo again when running ./build.sh the next time.

Yeah, our process here isn't great and it's why we're working to drive down the number of patches. Currently I go into the bin/src/<repo> directory (not bin/src/<repo>.<hash> as it's not an actual git directory), git am ../../../patches/<repo>/*, make my new change and commit it, git format-patch -o ../../../patches/<repo> <hash>, then git add the new patch, clean, and build.

crummel picture crummel on 6 Aug 2019

It's more complicated than I thought @wfurt:
Creating a PR with the above patches for the dotnet/roslyn repo would probably fix the FreeBSD build, but it would break the build for Windows and other platforms. The problem is that targeting netcoreapp2.1 and netcoreapp3.0 side-by-side is not possible everywhere in the project. So I would have to replace netcoreapp2.1 with netcoreapp3.0 in the whole project, which is a big change instead of a small patch. But I think it's going to be changed to netcoreapp3.0 in the future anyway. So maybe I can speed up this process a little bit...

joperator picture joperator on 7 Aug 2019
😄1

That make sense. I bump to something similar while back with coreclr. I can ask around what the plan is. As 3.0 is almost done, I would expect we would use it for building at some point.

wfurt picture wfurt on 7 Aug 2019

Hello!

I can get init-tools.sh work on FreeBSD 12 p9 Azure with DotNet3CLIVersion 3.0.100-preview7-012821 and BuildTools 3.0.0-preview7-27912-14
Additionally use the instructions above.

kldload linux.ko
kldload linux64
daydrim picture daydrim on 11 Aug 2019

Hello!
I can get init-tools.sh work on FreeBSD 12 p9 Azure with DotNet3CLIVersion 3.0.100-preview7-012821 and BuildTools 3.0.0-preview4-04212-02
Additionally use the instructions above.
kldload linux.ko
kldload linux64

I've stuck on step

Install missing libraries for LibGit2Sharp

pkg install libgit2
```
/root/dot-net/source-build/packages/microsoft.dotnet.arcade.sdk/1.0.0-dev.18424.13/tools/Build.proj(63,5): error : Property 'Projects' must be specified

Build FAILED.

/root/dot-net/source-build/packages/microsoft.dotnet.arcade.sdk/1.0.0-dev.18424.13/tools/Build.proj(63,5): error : Property 'Projects' must be specified
0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.57
Build failed (exit code '1').

'arcade' failed during build.
See '/root/dot-net/source-build/bin/logs/arcade.log' for more information.
'known-good' failed during build.
```

daydrim picture daydrim on 11 Aug 2019

running Linux runtime under emulation may work for simple app but I think it is dead end. It is not only about binaries but also some managed code is built from different sources. For example process management depends and some other functions do depend on Linux proc and that is incomplete under emulation.

Also note, that you cannot load FreeBSD libraries to Linux process. Using libgit2 from ports will not work wIth Linux SDK. You would need to get copy from Linux.

After all the long threads I'm wondering if we need to assemble new bootstrap cli. We may be able to keep runtime as it but drop new skd on top of it.

wfurt picture wfurt on 11 Aug 2019
👍1

Hello.
Yeap. I've recreated FreeBSD 12.0 Azure VM
linux compat is not enabled
Using the FreeBSD-latest.tar.gz

So the process stuck on libgit2 with different error:

pkg install libgit2
ln -s /usr/local/lib/libgit2.so /usr/local/lib/libgit2-572e4d8.so

./build.sh
 fail: Microsoft.DotNet.Darc.Operations.Operation[0]
        Something failed while cloning.
  System.Exception: Something went wrong when cloning repo https://github.com/dotnet/arcade at <default branch> into /root/git/dotnet/source-build/bin/src/arcade ---> System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.InvalidOperationException: Operation is not valid due to the current state of the object.
at LibGit2Sharp.Core.Platform.get_OperatingSystem()
     at LibGit2Sharp.Core.NativeMethods..cctor()
     --- End of inner exception stack trace ---
     at LibGit2Sharp.Core.NativeMethods.git_clone(git_repository*& repo, String origin_url, FilePath workdir_path, GitCloneOptions& opts)
     at LibGit2Sharp.Core.Proxy.git_clone(String url, String workdir, GitCloneOptions& opts)
     at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, CloneOptions options)
     at Microsoft.DotNet.DarcLib.RemoteRepoBase.Clone(String repoUri, String commit, String targetDirectory, ILogger _logger, String pat, String gitDirectory) in /root/git/dotnet/source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/RemoteRepoBase.cs:line 176
     --- End of inner exception stack trace ---

I guess it would be ideal if we can just switch between Core 2 and Core 3 build.sh . As for now we are trying to build Dotnet 2.1 project with 3.0 environment

daydrim picture daydrim on 12 Aug 2019

I guess it would be ideal if we can just switch between Core 2 and Core 3 build.sh.

Yeah, that would be great. But since this is not possible, you have to manually adjust the target framework in the project file.
I may have encountered a similar error as you described @daydrim when experimenting with Linux compatibility on FreeBSD. But as @wfurt has already described, this was a dead end for me, too. However, what I noticed when installing and uninstalling various Linux compatibility packages on FreeBSD was that LibGit2Sharp also failed with different exceptions. Since the NativeMethods constructor seems to be very error-prone on FreeBSD, it would be a good idea if you could run the build process again on a fresh VM and only perform the steps I described above.

joperator picture joperator on 12 Aug 2019

Today it starts to fail on init-tools.sh
I've redeploy FreeBSD 12.0 re-git and re-download dotnet-sdk-latest-freebsd.tar.gz
Do we have an URL to concrete version of dotnet.tar instead of
master ?
Or we need new versions of BuildTools and Dotnet3CLIVersion
How can we synchronize versions for builds ?
If we can choose versions we can do different tests

Is this the instruction to build new dotnet.tar for bootstrap CLI ?
https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD#building-freebsd-sdk

I agree with @wfurt that we we need to assemble new bootstrap cli

./init-tools.sh
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...
FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
   at System.Globalization.GlobalizationMode..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.CultureData.GetCultureData(System.String, Boolean)
   at System.Globalization.CultureInfo.InitializeFromName(System.String, Boolean)
   at System.Reflection.RuntimeAssembly.GetLocale()
   at System.Reflection.RuntimeAssembly.GetName(Boolean)
   at System.Diagnostics.Tracing.EventPipeController.GetAppName()
   at System.Diagnostics.Tracing.EventPipeController..ctor()
   at System.Diagnostics.Tracing.EventPipeController.Initialize()
   at System.StartupHookProvider.ProcessStartupHooks()
./init-tools.sh: line 200:  1709 Abort trap              (core dumped) "$__DOTNET_CMD" restore "$__INIT_TOOLS_RESTORE_PROJECT" --no-cache --packages "$__PACKAGES_DIR" --source "$__BUILDTOOLS_SOURCE" /p:BuildToolsPackageVersion=$__BUILD_TOOLS_PACKAGE_VERSION /p:ToolsDir="$__TOOLRUNTIME_DIR" >> "$__init_tools_log"
ERROR: Could not restore build tools correctly.
Please check the detailed log that follows.
R
...
Using RID linux-x64 for BuildTools native tools
Initializing BuildTools...

./init-tools.sh: line 221: /root/git/dotnet/source-build/packages/microsoft.dotnet.buildtools/3.0.0-preview4-04104-01/lib/init-tools.sh: No such file or directory
ERROR: An error occurred when trying to initialize the tools.
daydrim picture daydrim on 12 Aug 2019

Do we have an URL to concrete version of dotnet.tar instead of master?

The link that you posted is actually a concrete version of dotnet.tar. It's called master and latest but it hasn't changed since December 2018.

Is this the instruction to build new dotnet.tar for bootstrap CLI?

It's a part of the instructions. A starting point could be Build .NET Core from source. But most of the instructions (especially for FreeBSD and NetBSD) are out of date, I think.

joperator picture joperator on 13 Aug 2019

there is also https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD and https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD

Second ~6 month old. But even that is too old and out of sync as build changed a lot recently.

If there is interest we can probably come up with new instructions for 5.0 e.g. current master

wfurt picture wfurt on 13 Aug 2019
👍1

A starting point could be Build .NET Core from source. But most of the instructions (especially for FreeBSD and NetBSD) are out of date, I think.

Thanks! So @joperator @wfurt - what do you think? do we need new dotnet.tar for new test and experiments ?
I guess that preview 7 far more stable than previous versions of .net core 3 preview.
And the target patform is FreeBSD 12.0 for us.

daydrim picture daydrim on 13 Aug 2019

So just to clarify @daydrim: You want to create a new .NET Core 3.0 SDK for FreeBSD with the current .NET Core 3.0 SDK preview 7 (for Linux) as bootstrap CLI?

joperator picture joperator on 13 Aug 2019
👍1

You want to create a new .NET Core 3.0 SDK for FreeBSD with the current .NET Core 3.0 SDK preview 7 (for Linux) as bootstrap CLI?

Exactly . If it helps. @wfurt, @joperator, @crummel What's your opinion?

this instrunction https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD is based on Linux_compat - so it's outdated.
this instruction https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD - has the the link to dotnet.tar based on Linux_compat. And @joperator has more detailed instructions )))

@wfurt just to clarify: do you recommend switch from 3.0 to 5.0 ?
Because there are more chances to make Native Build ? If so for 5.0 we need different thread ))

daydrim picture daydrim on 13 Aug 2019

I don't know if this is possible @daydrim. I already accidentally tried to run ./build.sh with the .NET Core 3.0 SDK preview 6 for Linux as bootstrap CLI because the scripts decided to download and use that version instead of the .NET Core SDK for FreeBSD, which I specified as you can see above. The results were segmentation faults and core dumps even when running under Linux emulation, because as @wfurt pointed out:

I was on Linux path for a while until I realized that is dead-end path. Even if the binaries work under emulation it still uses many files from /proc and that will not work on FreeBSD.

So attempting to create a new .NET Core SDK for FreeBSD using the .NET Core SDK for Linux under emulation might be a solution - but I'm skeptical if it will work.

joperator picture joperator on 13 Aug 2019
👍1

So attempting to create a new .NET Core SDK for FreeBSD using the .NET Core SDK for Linux under emulation might be a solution - but I'm skeptical if it will work.

As far as I understand there is no need to enable linux emulation? or is this only in TBD?
https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md

daydrim picture daydrim on 13 Aug 2019

You don't need to enable Linux emulation to build the native components of the dotnet/coreclr repo, because you don't need a bootstrap CLI for that. But there are also managed components spread across several repos that need to be built using a bootstrap CLI. See Adding support for a new OS for more information.

joperator picture joperator on 13 Aug 2019

default version of coreclr in GitHub

~/git/coreclr # ./build.sh
Commencing CoreCLR Repo build
__DistroRid: freebsd.12-x64
__RuntimeId: freebsd.12-x64
Setting up directories for build
Checking prerequisites...
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.0.100-preview6-012264
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').
Failed to get PGO data package version.

I've changed the version in gloval.json
But the result is the same

 # ./build.sh
Commencing CoreCLR Repo build
__DistroRid: freebsd.12-x64
__RuntimeId: freebsd.12-x64
Setting up directories for build
Checking prerequisites...
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.0.100-preview7-012821
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').
Failed to get PGO data package version.

This is the first part of https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md

Build the Runtime
To build the runtime on FreeBSD, run build.sh from the root of the coreclr repository:
janhenke@freebsd-frankfurt:~/git/coreclr % ./build.sh

But as far as I understand it depends on the native part ?
https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md#build-the-framework-native-components

Native part builds without problems.

 # ./build-native.sh
Setting up directories for build
Checking pre-requisites...
Commencing build of corefx native components for FreeBSD.x64.Debug
Invoking "/root/git/corefx/src/Native/Unix/gen-buildsys-clang.sh" "/root/git/corefx/src/Native/Unix" "3" "9" "x64" "DEBUG" " -DFEATURE_DISTRO_AGNOSTIC_SSL=0 -DCMAKE_STATIC_LIB_LINK=0"
-- Configuring done
-- Generating done
-- Build files have been written to: /root/git/corefx/artifacts/obj/native/FreeBSD-x64-Debug
Executing make install -j 1
[ 17%] Built target System.IO.Compression.Native-Static
…
[100%] Built target System.Security.Cryptography.Native.OpenSsl
Install the project...
-- Install configuration: "DEBUG"
-- Installing: /root/git/corefx/src/Native/../../artifacts/bin/native/FreeBSD-x64-Debug/./System.IO.Compression.Native.so
…
-- Installing: /root/git/corefx/src/Native/../../artifacts/bin/native/FreeBSD-x64-Debug/./System.Security.Cryptography.Native.OpenSsl.a
#:~/git/corefx/src/Native #

So what should we do next ?
And how to resolve: dotnet_install: Error: Could not find/download:.NET Core SDKwith version = 3.0.100-preview7-012821
as described and then build Managed part?

https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md#build-the-framework-managed-components

And how to build the first part (Runtime) ?

daydrim picture daydrim on 13 Aug 2019

These are the same problems I ran into a few weeks ago until I found the dotnet/source-build repo, from which I hope it will be able to build all the necessary components to create a new .NET Core SDK for FreeBSD by simply specifying an existing bootstrap CLI. But as you can see, it's not that easy.

joperator picture joperator on 14 Aug 2019

Probably @wfurt or @crummel can help us with new Bootstrap CLI instructions.
Because it sems like there is a problem with downloading 3.0.100-preview6 and 7 SDK.

daydrim picture daydrim on 14 Aug 2019

I think the problem with downloading .NET Core 3.0 SDK preview 6 and 7 on FreeBSD is the RID freebsd-x64. The download link, which you should see in the build log, contains this RID:

Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview7-012821/dotnet-sdk-3.0.100-preview7-012821-freebsd-x64.tar.gz

This download fails because the file does not exist. Valid download links are https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview7-012821/dotnet-sdk-3.0.100-preview7-012821-linux-x64.tar.gz for the current preview of the .NET Core SDK for Linux and https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview-010021/dotnet-sdk-3.0.100-preview-010021-freebsd-x64.tar.gz for the old preview of the .NET Core SDK for FreeBSD.

joperator picture joperator on 14 Aug 2019

Sorry for the late response. I had to squash few more 3.0 issues but now back to fun:

I think the bootstrap is certainly part of the problem. I made updates to bring it more recent and I can build coreclr and corefx again. As we lost build servers (long story) it is unlikely that any new version will come out any time soon.

My original suggestion to focus on master branch was because it is very unlikely we will get approval for any changes for 3.0.

However, with https://github.com/dotnet/announcements/issues/119 .net build as we know now will burn in flames. It will ultimately make it easier to build, but 5.0 changes will also bring lot of instability and changes.

I don't know what the motivation is @joperator and @daydrim but perhaps we could/should focus on recreating 3.x releases for FreeBSD. If source-build can take changes and patches, that can be viable path and it can provide some value. Maintaining patches instead of making code changes is tedious but hopefully release/3.0 branches will be pretty stable at this point.

If you agree, please let me know.

I'm in process of updating https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD to reflect current status as well as instructions how to update bootstrap cli.

I did not try source-build yet. I want to make sure important repos do build before trying to build everything together.

wfurt picture wfurt on 16 Aug 2019
👍1

As far as the core-setup @crummel: do you know what SDK version we would need to avoid building Roslyn? Updating that in bootstrap cli would be easy but I did bump to some issues as there are some JSON changes and Arcade cannot find proper types.

wfurt picture wfurt on 16 Aug 2019

I actually thought we had gotten by the JSON changes around preview4 and 5. The more recent issues I've seen have been with nullable reference types, but I think those should be resolved as of preview7. If you want to try building the runtime without Roslyn you can remove the references in coreclr.proj and core-setup.proj and build with /p:RootRepo=core-setup, that should take Roslyn out of the tree completely and we should just use the bootstrap SDK instead. If you try that out and have specific issues I can take a look at the binlogs.

crummel picture crummel on 16 Aug 2019

I don't know what the motivation is @joperator and @daydrim but perhaps we could/should focus on recreating 3.x releases for FreeBSD. If source-build can take changes and patches, that can be viable path and it can provide some value. Maintaining patches instead of making code changes is tedious but hopefully release/3.0 branches will be pretty stable at this point.

Agree with that.
As of me, my motivation is to commit and maintain netcore3.0 port for FreeBSD Community. I think it can provide some value and great experience.

I'm in process of updating https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD to reflect current status as well as instructions how to update bootstrap cli.

Thanks a lot!
Can you mark which parts require Linux compatibilty and which do not.
Because there are some links in the instruction such as:

Let's get SDK for supported OS. Sync code base to same version you are trying to build on FreeBSD.

> ./eng/common/build.sh --restore
> Downloading 'https://dot.net/v1/dotnet-install.sh'
> dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview6-012264/dotnet-sdk-3.0.100-preview6-012264-linux-x64.tar.gz

And the result is (because linux compatibility is not enabled)

 ~/dotnet/sdk/source-build]$ ./eng/common/build.sh --restore
dotnet_install: Warning: Unable to locate libunwind. Probable prerequisite missing; install libunwind.
dotnet_install: Warning: Unable to locate libssl. Probable prerequisite missing; install libssl.
dotnet_install: Warning: Unable to locate libicu. Probable prerequisite missing; install libicu.
dotnet_install: Warning: Unable to locate libcurl. Probable prerequisite missing; install libcurl.
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview7-012821/dotnet-sdk-3.0.100-preview7-012821-linux-x64.tar.gz
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview7-012821/dotnet-sdk-3.0.100-preview7-012821-linux-x64.tar.gz
export UNAME_s=dotnet-install: Adding to current process PATH: `/usr/home/daydrim/dotnet/sdk/source-build/.dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.
ELF binary type "0" not known.
/usr/home/daydrim/dotnet/sdk/source-build/eng/common/tools.sh: line 296: /usr/home/daydim/dotnet/sdk/source-build/.dotnet/dotnet: cannot execute binary file: Exec format error
Build failed (exit code '126').

Also we can switch the RID if needed:
$ export UNAME_s=Linux
and then check

$ uname -a
Linux bsd11 11.3-RELEASE-p2 FreeBSD 11.3-RELEASE-p2 #0: Tue Aug  6 05:07:20 UTC 2019     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64
$ uname -s
Linux

One more issue:

Instructions were tested on plain FreeBSD 11.3 Azure image

There is no plain FreeBSD 11.3 Azure image in the Catalog available at the moment.
We can only choose between plain FreeBSD 10.4 / 11.2 / 12.0 and if we use 11.2 we can update it manually to 11.3 according to FreeBSD Handbook

Or we can create new thread (issue) for the instruction ? and pull only the instructions as pull request if find some tiny fixes ? If 'yes' I'll do that

daydrim picture daydrim on 17 Aug 2019

If you agree, please let me know.

I totally agree with you @wfurt. My motivation is to create applications and libraries that can run on different platforms like Windows, Linux and FreeBSD without having binaries for each platform and without needing Mono.

I made updates to bring it more recent and I can build coreclr and corefx again.

I'm in process of updating https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD to reflect current status as well as instructions how to update bootstrap cli.

Very nice to hear that there's some progress with these repos and the documentation. So if coreclr and corefx can be built again, is the next step to get source-build (without Roslyn) working again by creating patches for release/3.0?

joperator picture joperator on 19 Aug 2019

I did more updates to notes @joperator and @daydrim as well as I added link to download updated cli if somebody wants to skip all the steps for now. Building and running corefx tests is still a challenge.

I think getting source-build with or without Roslyn working is good milestone. As minimum it will outline gaps and we should get as much as possible changes to individual repos. Even if that will change in future, there is chance that changes will be carried forward. I think we should work with @crummel to get much as /p:RootRepo=coreclr, /p:RootRepo=corefx and /p:RootRepo=core-setup working.

wfurt picture wfurt on 20 Aug 2019

Issues with LibGit2Sharp should be fixed by https://github.com/dotnet/sourcelink/pull/288
(it may not make it to 3.0 branches)

wfurt picture wfurt on 20 Aug 2019

... I added link to download updated cli if somebody wants to skip all the steps for now.

This sounds great @wfurt. But actually I think I found some bugs when trying to build a .NET Core app targeting netcoreapp3.0 with your updated CLI:

Microsoft (R) Build Engine version 16.3.0-preview-19325-02+eca7818b1 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 3.0.0-preview7-27826-04)
~/ConsoleAppCore.csproj : error NU1102:   - Found 6 version(s) in nuget.org [ Nearest version: 3.0.0-preview7-27912-14 ]
~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Host.linux-x64 with version (= 3.0.0-preview7-27826-04)
~/ConsoleAppCore.csproj : error NU1102:   - Found 4 version(s) in nuget.org [ Nearest version: 3.0.0-preview7-27912-14 ]
~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.AspNetCore.App.Ref with version (= 3.0.0-preview7.19325.7)
~/ConsoleAppCore.csproj : error NU1102:   - Found 6 version(s) in nuget.org [ Nearest version: 3.0.0-preview7.19365.7 ]
  Restore failed in 728.67 ms for ~/ConsoleAppCore.csproj.

Build FAILED.

~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 3.0.0-preview7-27826-04)
~/ConsoleAppCore.csproj : error NU1102:   - Found 6 version(s) in nuget.org [ Nearest version: 3.0.0-preview7-27912-14 ]
~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Host.linux-x64 with version (= 3.0.0-preview7-27826-04)
~/ConsoleAppCore.csproj : error NU1102:   - Found 4 version(s) in nuget.org [ Nearest version: 3.0.0-preview7-27912-14 ]
~/ConsoleAppCore.csproj : error NU1102: Unable to find package Microsoft.AspNetCore.App.Ref with version (= 3.0.0-preview7.19325.7)
~/ConsoleAppCore.csproj : error NU1102:   - Found 6 version(s) in nuget.org [ Nearest version: 3.0.0-preview7.19365.7 ]
    0 Warning(s)
    3 Error(s)

Replacing all occurrences of not found versions with the specified nearest versions in your updated CLI seems to fix these bugs and let me build (and run) the .NET core app again.

joperator picture joperator on 21 Aug 2019

oh, I probably forget to mention this in note. We publish to Nuget only certain version and rest goes to transient blob storage. I have this in my NuGet config

   <add key="dotnet-core" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
   <add key="aspnet-core" value="https://dotnetfeed.blob.core.windows.net/aspnet-aspnetcore/index.json" />

Or you would need to pass it in as extra restore sources. That should not be problem once we sync up to official releases.

For CoreCLR I use -skipmanagedtools so it does not need ASP.NET at all. But it may be needed in some other places.

Also note that on current platforms, we bundle ASP in SDK but we do not on FreeBSD as there was no runtime as well as it was hard to build ASP without stable cli. There may be still some odd ends.

wfurt picture wfurt on 21 Aug 2019

Glad to hear about the changes...
So even with that keys there are errors with .build.sh
It looks like we need to disable .netcoreapp22
OS: FreeBSD 11.3 p3

Making all .sh files executable under Tools.
  Restoring packages for /usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj...
/usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj : error NU1202: Package Microsoft.NETCore.App 3.0.0-preview-27218-01 is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2). Package Microsoft.NETCore.App 3.0.0-preview-27218-01 supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
/usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj : error NU1202: Package Microsoft.NETCore.App 3.0.0-preview-27218-01 is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2) / linux-x64. Package Microsoft.NETCore.App 3.0.0-preview-27218-01 supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
  Generating MSBuild file /usr/home/daydrim/source-build/Tools/crossgen/obj/crossgen.csproj.nuget.g.props.
  Generating MSBuild file /usr/home/daydrim/source-build/Tools/crossgen/obj/crossgen.csproj.nuget.g.targets.
  Restore failed in 438.31 ms for /usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj.
daydrim picture daydrim on 22 Aug 2019

@daydrim: Did you notice the following steps from the instructions?

and apply following patch (to get https://github.com/dotnet/source-build/pull/631)

Set variables and assemble SKD without crossgen. (set DropSuffix=true to strip preview6 from version).
export DISABLE_CROSSGEN=true

joperator picture joperator on 23 Aug 2019

Did you notice the following steps from the instructions?

Yeap. I've tried
export DISABLE_CROSSGEN="true"
and change core-setup.proj
<BuildArguments Condition="'$(TargetOS)' == 'FreeBSD'">$(BuildArguments) -DisableCrossgen=true</BuildArguments>

The result of build.sh from source-build is the same

Making all .sh files executable under Tools.
  Restoring packages for /usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj...
/usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj : error NU1202: Package Microsoft.NETCore.App 3.0.0-preview-27218-01 is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2). Package Microsoft.NETCore.App 3.0.0-preview-27218-01 supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
/usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj : error NU1202: Package Microsoft.NETCore.App 3.0.0-preview-27218-01 is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2) / linux-x64. Package Microsoft.NETCore.App 3.0.0-preview-27218-01 supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
  Generating MSBuild file /usr/home/daydrim/source-build/Tools/crossgen/obj/crossgen.csproj.nuget.g.props.
  Generating MSBuild file /usr/home/daydrim/source-build/Tools/crossgen/obj/crossgen.csproj.nuget.g.targets.
  Restore failed in 476.24 ms for /usr/home/daydrim/source-build/Tools/crossgen/crossgen.csproj.
daydrim picture daydrim on 23 Aug 2019

That's weird @daydrim because I do almost the same things there as you do. The only difference I see at the moment is that I'm building in a FreeBSD 12.0 VM while you're building on FreeBSD 11.3 - but I don't think this is the cause of the problem. Maybe @wfurt knows more.

I wrote some patches to make source-build work as much as possible using your updated .NET Core SDK for FreeBSD as bootstrap CLI, as you recommended @wfurt:
source-build-freebsd-patches.zip

With different command line switches I now get the following results when running ./build.sh:

  • Without command line switches:
    'known-good' failed during build.
    But there's no hint why known-good failed.
  • With /p:RootRepo=corefx /p:SkipRepoReferences=true:
    /root/git/dotnet/source-build/bin/src/corefx.1bb52e6a3db7f3673a3825f3677b9f27b9af99aa/eng/depProj.targets(101,5): error : Error no assets were resolved from NuGet packages. [/root/git/dotnet/source-build/bin/src/corefx.1bb52e6a3db7f3673a3825f3677b9f27b9af99aa/external/tools/tools.depproj]
  • With /p:RootRepo=core-setup /p:SkipRepoReferences=true:
    /root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/pkg/packaging-tools/framework.dependency.targets(229,5): error : Required property _runtimePackageDir with value '/root/git/dotnet/source-build/packages/transport.runtime.freebsd.12-x64.microsoft.netcore.runtime.coreclr/3.0.0-dev.19379.2/' does not exist. [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/pkg/projects/netcoreapp/src/netcoreapp.depproj]
    Does anyone have an idea how these issues can be solved or at least can explain to me what the problems are?
joperator picture joperator on 28 Aug 2019

If you haven't yet, you might want to rebase your work on the latest release/3.0. We started building the runtime as portable - this is the only way SkipRepoReferences=true will work since you won't be building the non-portable assets that core-setup and corefx expect. bin/logs/corefx.log and bin/logs/core-setup.log should have more details, or there should be even more detail in bin/src/<repo>.<hash>/artifacts/log.

crummel picture crummel on 28 Aug 2019

I made some progress over the weekend but I did not have time to update this issue. I'm building on 11.3 and I can build whole runtime (up to core-setup) if I skip Roslyn as @crummel suggested.

As was planning to post PR with some improvements.
I will review and incorporate posted patches as I see fit @joperator

As far as the Microsoft.AspNetCore.App.Ref error: remove reference to it in Microsoft.NETCoreSdk.BundledVersions.props. As we get updated SDK from Linux it assumes it is bundled in but it is not on FreeBSD. I will post updated cli but I wanted to do more testing before that.

As far as the the 2.x vs 3.0 targeting: there may be some tricks we can play. I'm still trying to sort this out and talking few experts around. We may just fake old version to keep build happy for now.

wfurt picture wfurt on 28 Aug 2019
👍2

I'm trying to run ./build.sh /p:RootRepo=core-setup /p:SkipRepoReferences=true on FreeBSD 12.0 without Roslyn using the release/3.0 branch, but that doesn't seem to work:

Found 2.x SDK 3.0.100-preview7-012630, 3.x SDK 3.0.100-preview7-012821, Arcade bootstrap 1.0.0-beta.19359.6
warning: submodule tools-local/arcade-services has uncommitted changes

Tools are already initialized
Microsoft (R) Build Engine version 16.3.0-preview-19325-02+eca7818b1 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

/root/git/dotnet/source-build/Tools/dotnetcli/sdk/3.0.100-preview7-012630/MSBuild.dll /bl:build.binlog /clp:v=m /flp:v=diag /p:RootRepo=core-setup /p:SkipRepoReferences=true /root/git/dotnet/source-build/build.proj
  core-setup using package version properties saved at /root/git/dotnet/source-build/bin/obj/x64/Release/PackageVersions.props.pre.core-setup.xml 
  Checked cache for conflicts with source-built nupkgs.
  Building 'core-setup'
  Running command:
    /root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c//build.sh --restore --build --configuration Release --ci /p:DisableCrossgen=true /p:BuildDebPackage=false /p:BuildAllPackages=true /p:RestoreAllBuildRids=false /p:PreReleaseLabel="preview8" /p:DotNetOutputBlobFeedDir=/root/git/dotnet/source-build/bin/obj/x64/Release/blob-feed/ --verbosity minimal --binaryLog  /p:DotNetPackageVersionPropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/PackageVersions.props /p:DotNetRestoreSourcePropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/RestoreSources.props
    Log: /root/git/dotnet/source-build/bin/logs/core-setup.log
    With Environment Variables:
      DOTNET_TOOL_DIR=/root/git/dotnet/source-build/Tools/dotnetcli3/
      DotNetToolPath=/root/git/dotnet/source-build/Tools/dotnetcli3/
      DotNetTool=/root/git/dotnet/source-build/Tools/dotnetcli3/dotnet
      BUILD_TOOLS_TOOL_DIR=/root/git/dotnet/source-build/Tools/
      BUILDTOOLS_SKIP_CROSSGEN=1
      DotNetBuildFromSource=true
      DotNetRestorePackagesPath=/root/git/dotnet/source-build/packages/
      DotNetCoreSdkDir=/root/git/dotnet/source-build/Tools/dotnetcli3/
      DotNetBuildToolsDir=/root/git/dotnet/source-build/Tools/source-built
      DotNetRoot=/root/git/dotnet/source-build/Tools/dotnetcli3/
      DOTNET_PATH=/root/git/dotnet/source-build/Tools/dotnetcli3/
      DOTNET_HOST_PATH=/root/git/dotnet/source-build/Tools/dotnetcli3/dotnet
      _InitializeDotNetCli=/root/git/dotnet/source-build/Tools/dotnetcli3/
      _DotNetInstallDir=/root/git/dotnet/source-build/Tools/dotnetcli3/
      _InitializeToolset=/root/git/dotnet/source-build/Tools/source-built/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj
      BuildToolsPackageDir=/root/git/dotnet/source-build/Tools/source-built
      StabilizePackageVersion=false
      PB_IsStable=false
      DotNetUseShippingVersions=true
      ContinuousIntegrationBuild=true
      MSBUILDDEBUGPATH=/root/git/dotnet/source-build/bin/msbuild-debug/
      MSBUILDDEBUGCOMM=1
      MSBUILDDEBUGSCHEDULER=1
      MSBUILDDEBUGFORCECACHING=1
      MSBUILDDEBUG=1
      MSBUILDDEBUGEVALUATION=1
      MSBUILDTARGETOUTPUTLOGGING=1
      MSBUILDLOGTASKINPUTS=1
      MSBUILDEMITSOLUTION=1
      MSBUILDLOGVERBOSERARSEARCHRESULTS=1
      RoslynCommandLineLogFile=/root/git/dotnet/source-build/bin/roslyn-debug/
      MSBUILDDISABLENODEREUSE=1
      OfficialBuildId=20280805.7
      BUILD_BUILDNUMBER=20280805.7
      GitCommitCount=6217
      GitCommitHash=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      GitInfoCommitHash=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      SourceRevisionId=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      RepositoryCommit=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      COMMIT_SHA=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      GIT_COMMIT=d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c
      PreReleaseVersionLabel=preview8
      PackageVersionStamp=preview8
      PB_VersionStamp=preview8
      RepositoryType=Git
      DeterministicSourcePaths=true
      SOURCE_BUILT_SDK_ID_ARCADE=Microsoft.DotNet.Arcade.Sdk
      SOURCE_BUILT_SDK_VERSION_ARCADE=1.0.0-beta.19381.1
      SOURCE_BUILT_SDK_DIR_ARCADE=/root/git/dotnet/source-build/Tools/source-built/Microsoft.DotNet.Arcade.Sdk/
/root/git/dotnet/source-build/repos/dir.targets(234,5): error MSB3073: The command "/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c//build.sh --restore --build --configuration Release --ci /p:DisableCrossgen=true /p:BuildDebPackage=false /p:BuildAllPackages=true /p:RestoreAllBuildRids=false /p:PreReleaseLabel="preview8" /p:DotNetOutputBlobFeedDir=/root/git/dotnet/source-build/bin/obj/x64/Release/blob-feed/ --verbosity minimal --binaryLog  /p:DotNetPackageVersionPropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/PackageVersions.props /p:DotNetRestoreSourcePropsPath=/root/git/dotnet/source-build/bin/obj/x64/Release/RestoreSources.props >> /root/git/dotnet/source-build/bin/logs/core-setup.log 2>&1" exited with code 1. [/root/git/dotnet/source-build/repos/core-setup.proj]
  MSBUILD : error MSB1009: Project file does not exist.
  Switch: /root/git/dotnet/source-build/Tools/source-built/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj
  ##vso[task.logissue type=error]Build failed (exit code '1').

  'core-setup' failed during build.
  See '/root/git/dotnet/source-build/bin/logs/core-setup.log' for more information.

Contrary to what is claimed, core-setup.log does not provide more information. It only contains the same message about the missing project file. bin/src/core-setup.<hash>/artifacts/log contains only an empty folder named Release. As the missing project file is supposed to be inside the Tools folder, I assume that it should be created while running init-tools.sh. But the folder Tools/source-built/Microsoft.DotNet.Arcade.Sdk does not exist after that. Which command or script should create this folder and the project file?
The same problem also applies to ./build.sh /p:RootRepo=corefx /p:SkipRepoReferences=true.

joperator picture joperator on 4 Sep 2019

You can try to add -x to core-setup's build.sh to make it more verbose. You can also try to execute it directly to get more feedback. For now, I'm focusing on 11.3. I did not find enough time to cleanup my changes and turn them to PR.

wfurt picture wfurt on 4 Sep 2019

Ah, you're not getting Arcade. Could you try ./build.sh /p:RootRepo=arcade /p:SkipRepoReferences=true first, then the core-setup version?

crummel picture crummel on 4 Sep 2019

Thanks for your advice @crummel. After building arcade first, building core-setup continues, but now I get the following error for several projects:

"/root/git/dotnet/source-build/Tools/source-built/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj" (default target) (1) ->
"/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj" (Build target) (9:7) ->
(InitializeSourceControlInformationFromSourceControlManager target) -> 
  /root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error : The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf) [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Core.Proxy.git_buf_free(GitBuf buf) [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Core.Handles.GitBuf.Dispose() [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever) [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Core.Proxy.git_repository_discover(FilePath start_path) [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at LibGit2Sharp.Repository.Discover(String startingPath) [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at Microsoft.Build.Tasks.Git.GitOperations.LocateRepository(String directory) in /_/src/Microsoft.Build.Tasks.Git.Operations/GitOperations.cs:line 26 [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]
/root/git/dotnet/source-build/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): error :    at Microsoft.Build.Tasks.Git.RepositoryTasks.LocateRepository(LocateRepository task) in /_/src/Microsoft.Build.Tasks.Git.Operations/RepositoryTasks.cs:line 58 [/root/git/dotnet/source-build/bin/src/core-setup.d01b2fb7bc6bd4911e157fbd51353059a3ba1a6c/src/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj]

I've fixed a similar error before by installing libgit2 and creating a symlink for /usr/local/lib/libgit2.so, but now I have no idea what is causing the current exception.

joperator picture joperator on 6 Sep 2019

Hmm, sourcelink isn't supposed to have a dependency on libgit anymore. I'll look into this after we finish up preview9, we might just have to update our sourcelink hash.

crummel picture crummel on 13 Sep 2019

Do you guys keep any records (like summary of the conversation above) with the progress of building SDK 3.0 RTM? Thank you for your efforts!

FeodorFitsner picture FeodorFitsner on 3 Oct 2019

Hmm, not really, the closest thing is probably the commit history and comments on that PR. If you have specific questions I'm probably the one that can answer them.

Also, @joperator, I'll be updating sourcelink in https://github.com/dotnet/source-build/pull/1237 so hopefully that'll fix that issue.

crummel picture crummel on 3 Oct 2019

That sounds good @crummel. I've already tried to build your arcadeUpgrade branch in the crummel/dotnet_source-build repo, but without success because I can't install the bootstrap CLI since init-tools.sh has been removed. I copied the bootstrap CLI into the .dotnet folder, but that didn't work either due to the following error:

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=/root/git/crummel/dotnet_source-build
+ '[' false == true ']'
+ /root/git/crummel/dotnet_source-build/eng/common/build.sh --restore --build -c Release --warnaserror false /p:Projects=/root/git/crummel/dotnet_source-build/build.proj
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').

Are there any updates on how to install the bootstrap CLI now?

joperator picture joperator on 4 Oct 2019
👍1

If you're looking for a recent SDK for FreeBSD 12 you can take a look here.
Ensure you install the packages in DotNet3.0.0_BasePackages_FreeBSD.12.tar
https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD-12

jasonpugsley picture jasonpugsley on 15 Oct 2019
👍1

Thanks for the guide you provided, @jasonpugsley.
I'm able to build coreclr and core-setup as you described, but I had / have problems building corefx and core-sdk:

  • corefx tried to restore NuGet packages that did not exist:
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102: Unable to find package runtime.freebsd-x64.Microsoft.NETCore.ILAsm with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102: Unable to find package runtime.freebsd-x64.Microsoft.NETCore.ILDAsm with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102: Unable to find package runtime.freebsd-x64.Microsoft.NETCore.Runtime.CoreCLR with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102: Unable to find package runtime.freebsd-x64.Microsoft.NETCore.Jit with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/tools/tools.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102: Unable to find package runtime.freebsd-x64.Microsoft.NETCore.TestHost with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102: Unable to find package transport.runtime.freebsd-x64.Microsoft.NETCore.Runtime.CoreCLR with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102: Unable to find package transport.runtime.freebsd-x64.Microsoft.NETCore.Jit with version (>= 3.0.0-rc2.19462.5) [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 153 version(s) in dotnet-core [ Nearest version: 3.0.0-preview1-27131-02 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 51 version(s) in dotnet-coreclr [ Nearest version: 3.0.0-preview-27525-73 ] [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in local_pkgs [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in nuget.org [/root/git/dotnet/corefx/external/dir.proj]
/root/git/dotnet/corefx/external/runtime/runtime.depproj : error NU1102:   - Found 0 version(s) in darc-pub-dotnet-standard-a5b5f2e [/root/git/dotnet/corefx/external/dir.proj]
    0 Warning(s)
    7 Error(s)

I could fix this by removing .12 from the filenames of your NuGet packages as well as from the id and title in the contained .nuspec files. But I think the real problem is that the corefx build misses the .12 suffix when trying to restore packages.

  • core-sdk build failed due to the following errors:
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Runtime/2.1.0/dotnet-runtime-2.1.0-freebsd-x64.tar.gz
curl: (22) The requested URL returned error: 404 
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Runtime/2.1.0/dotnet-runtime-2.1.0-freebsd-x64.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core Runtime` with version = 2.1.0
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
/root/git/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 /root/git/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. [/root/git/dotnet/core-sdk/test/Microsoft.DotNet.Tools.Tests.Utilities/Microsoft.DotNet.Tools.Tests.Utilities.csproj]
/root/git/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 /root/git/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. [/root/git/dotnet/core-sdk/src/SdkResolver/SdkResolver.csproj]
/root/git/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 /root/git/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. [/root/git/dotnet/core-sdk/src/Microsoft.Dotnet.Sdk.Internal/Microsoft.Dotnet.Sdk.Internal.csproj]
/root/git/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 /root/git/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.
  core-sdk-tasks -> /root/git/dotnet/core-sdk/artifacts/bin/core-sdk-tasks/Release/netcoreapp3.0/core-sdk-tasks.dll
/root/git/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 /root/git/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. [/root/git/dotnet/core-sdk/src/core-sdk-tasks/core-sdk-tasks.csproj]

As you said, we can ignore the errors about dotnet 2.1.0, but the other errors with the Microsoft.DotNet.Arcade.Sdk.CalculateAssemblyAndFileVersions task seem to be more important because artifacts/packages doesn't exist after building core-sdk. Do you have any idea how to fix this?

And I think I found some small mistakes in the patches that are included in your guide:

  • corefx: pkg/Microsoft.Private.CoreFx.NETCoreApp/netcoreapp.rids.props starts with a kind of byte order mark tags <EF><BB><BF>. Remove these tags.
  • core-setup: Missing lines after the removed lines in Directory.Build.props. I think it should be
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -224,8 +224,6 @@

   <PropertyGroup>
     <DisableCrossgen>false</DisableCrossgen>
-    <!-- Disable cross-gen on FreeBSD for now. This can be revisited when we have full support. -->
-    <DisableCrossgen Condition="'$(OSGroup)'=='FreeBSD'">true</DisableCrossgen>
     <OutputVersionBadge>$(AssetOutputPath)sharedfx_$(OutputRid)_$(ConfigurationGroup)_version_badge.svg</OutputVersionBadge>
   </PropertyGroup>

Maybe you could adjust that in the guide.

joperator picture joperator on 17 Oct 2019

Thank you for the feedback. The missing packages you're seeing with corefx probably means it's
not looking in your local package staging directory first.
Try clearing all of the caches, the global one is
~/.nuget/packages/
Then each repo may have one too. e.g
.packages/ for coreclr and core-setup
.nuget/packages/ for core-sdk

The error you're seeing with core-sdk probably requires you to clear the caches too.

Ensure the local pkg source has been configured correctly.

Oh, and use this guide now https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD

jasonpugsley picture jasonpugsley on 18 Oct 2019
👍1

Thank you very much for updating your guide, @jasonpugsley.
Building corefx now works without adjustments.
I still had the same issues when building core-sdk even after clearing the NuGet cache and ensuring that the local package source was configured correctly. After renaming the local package source, trying to build core-sdk again, re-renaming the local package source and clearing all NuGet caches between each step, the build suddenly works.
@wfurt, @crummel: Can we use this guide to build more of source-build?

joperator picture joperator on 21 Oct 2019

I wanted to try instructions and execute all corefx tests once again. What is problem with SDK @joperator ? Roslyn once again? I asked few colleagues but I did not get good answer how to approach that.

wfurt picture wfurt on 21 Oct 2019

Aside from the building of the SDK that is installed from the dotnet-sdk-3.0.100-freebsd-x64.tar.gz archive, there are a set of nuget packages that the builds create. Some of these are important for building the SDK itself, some may be needed for building other software.

We need to decide where to host these packages so they're easily available during a "restore" operation. It may also require some already-published official parent packages to be updated to have references to our packages - though I haven't done an audit to see which, if any, these would be. I expect the packages for release 3.0 are frozen anyway, but maybe 3.1 could have FreeBSD packages officially hosted if the testing that @wfurt mentions meets the required pass-rate?

Otherwise, we _should_ look at hosting them somewhere semi-official and put instructions together to edit the user's nuget configuration so it first looks there for packages during restore.

I'm suggesting this in order to have FreeBSD appear, as much as possible, to be part of the .Net Core community during the lifetime of 3.1. I feel it would be a bit of a shame to have to wait on the outskirts for another year before joining in with .Net 5.

The goal should be to make it easy for newcomers to start using .Net Core on FreeBSD. If we can remove any barriers to adoption then it should be easier to gauge real interest in this project and so how much extra effort it warrants putting in.

Maybe this discussion should move to a separate issue rather than go off topic?

jasonpugsley picture jasonpugsley on 22 Oct 2019

The current problem with the release/3.0 branch in source-build is that it does not find the bootstrap CLI anymore, as I mentioned here. So I'm not sure if work should continue in the release/3.0 branch or in master where it's still possible to initialize the bootstrap CLI. Maybe you know, @wfurt.
If it's master, I would give the self-built .NET Core SDK a try to build source-build perhaps with Roslyn.

Another point of interest would be whether it might again be possible to provide a daily build of the .NET Core SDK for FreeBSD using this guide and share the created NuGet packages as recommended by @jasonpugsley.

joperator picture joperator on 22 Oct 2019

I need to find some time and give it another try @joperator. The bootstrap should work AFAIK as long as it is (or pretends to) be the _same_ version as build expects. I got in change for new FreeBSD RIDs but I need to figure out if we would be allowed to bring that to 3.x.

wfurt picture wfurt on 24 Oct 2019

@wfurt, I was told by @danmosemsft that backporting RIDs for newer versions of platforms to existing release branches is a "tell mode" feature and not an "ask mode". Didn't sound like ship room would have any objections:

We agreed in shiproom that updates of this sort to maintain our OS support do not need approval.

From https://github.com/dotnet/corefx/pull/41605

omajid picture omajid on 24 Oct 2019

FreeBSD is not in the official support matrix - therefore it's a little different to just continuing to maintain our existing support commitments. It's not necessarily a problem, it would just need to have a formal conversation. That would probably start with putting a PR up.

danmoseley picture danmoseley on 24 Oct 2019
👍1

Thanks for correcting me!

omajid picture omajid on 24 Oct 2019

That link points to different OS @danmosemsft. We don't even have one for FreeBSD :)
However, we do have RID already in 3.0 and #40865 was to make update to reflect version updates. I'll try to clarify willingness to take change and I'll follow-up on this thread later.

wfurt picture wfurt on 24 Oct 2019
👍1

You're right @wfurt, bad link. Yep, not pushing back, just responding to question about process.

danmoseley picture danmoseley on 24 Oct 2019

What else is required to reenable official builds of the SDK for FreeBSD?
Do we actually need all of source-build or can we get away with just
coreclr, corefx, core-setup & core-sdk?

dotnet/core-setup#5083

jasonpugsley picture jasonpugsley on 25 Oct 2019

Long term; fingers crossed

I think the smoothest path would be if AzDO team proceed with https://github.com/microsoft/azure-pipelines-agent/pull/1906.
Then runtime and sdk repos will get the proper CI/CD setup for FreeBSD. Note that FreeBSD was enabled in coreclr, corefx, core-setup back in Jenkins days (2015 to late-2018), as the CIaaS was switched to AzDO, FreeBSD leg was lost due to the lack of FreeBSD agent in public pool.

(aside from thumbing up https://github.com/microsoft/azure-pipelines-agent/pull/1906 to show our supports)

Short term; right now

For comparison, CirrusCI uses Google cloud for public FreeBSD jobs since Dec 4, 2018. e.g. corefx/.cirrus.yml. If it makes sense; we can, meanwhile, make it publish releases to your fork (@jasonpugsley). I have the pluming done elsewhere, which builds the binaries, creates github release and uploads artifacts to github release: example. The limit is 2 GB per file and we can have many assets and distribute them reliably. #it-scales

am11 picture am11 on 25 Oct 2019

Instructions @jasonpugsley put together worked reasonably well for me. There are again some changes but I was able to build all interesting repos and even run corefx tests after long time.
There are some issues we should fix but as bonus I got Filesystem.Watcher working as well. (or at least pass all existing tests)
I think next step really is stabilizing source-build and getting fixes to master. Repo reorg is near by and after it is done we should focus on bringing support again to master.
I'll try to get in as much as I can.

wfurt picture wfurt on 8 Nov 2019
👍2 ❤1

There is still hope for .NET. He needs time... and safe passage across the plains of Gorgoroth. We can give him that!
Certainty of death, small chance of success... What are we waiting for?

Let's march to the Black Gate!

  • I was chasing the linker checkout problem. It fails with weird Linq exception deep in darc code. The fact that it does not show immediately is probably source-build or darc bug @crummel .
    However, setting LANG=en_US.UTF-8 fixes it. I have my suspicions but for now, I'll ignore it as we have workaround.
    Note, that running git clean -dfx or clean.sh doews not recover. I had to blow up my whole build tree and that looks like another source-build bug. I would expect predictable way how to turn source tree to good know state.

  • I found a trick how to build Roslyn (and perhaps others) without any modifications.
    https://onedrive.live.com/?authkey=%21AEqa66wLAgAyow4&id=51291C5127B9C256%21252&cid=51291C5127B9C256 has set of 2.1.x packages. When dropped to custom package folder, they should allow to target 2.1 on FreeBSD. I did not really build 2.1. I used binaries @jasonpugsley built but I re-packed them as 2.1. I'l post instructions later but with symlink 3.0.0. as 2.1.0 and 2.1.90 in bootstrap cli, I got over that hump. Unfortunately, official packages no longer have entry for FreeBSD RID. To avoid conflicts I published everything as 2.1.90 to make it clear this is stub as well as to be sure we always win. I wish we only need one version of cli to built current product but I'm skeptical we get there any time soon ;(

  • I'm trying to avoid modification to system it self and source code it self. When possible, I'm trying to use environment variable to build parameter. For now, I copy all pre-built packages to bin/obj/x64/Release/blob-feed/packages/ to avoid need to modify Nuget.config in each repo.
    @crummel may have better ideas. Bash and Sourcelink is yet to be dealt with.
  • I and @am11 put in few more FreeBSD changes to CoreFX over the weekend. They are not critical for build it self but we should work out how to get them in.
  • I'll submit PR to source build with essential fixes. Parameters when possible and patch file when needed.
  • back to @joperator complain: I put my cli on PATH as well as I use link -s to create expected version. With that, I can avoid need to dotnet-install.sh. Hardcoded call for 2.1 is unfortunate IMHO. I should be possible to crate needed dependencies outside of source-build and use them as need instead of source-build forcing download from only official sources. For now, I simply commented that out but we can perhaps check if needed runtime is available and if so skip the download and install.

It would be great if @jasonpugsley can update notes and rebuild final 3.0 bits. All 3.x branches as well as master need that so we should get good milage out of it.

.NET repose as we know them will disappear tomorrow. I think we should have separate issue to address 5.0/master. It should be easier IMHO but it will be radically different.

It would be great if @joperator can give it another try. The build seems fragile and I can get different results without any changes but I was able to move on with persistence.

wfurt picture wfurt on 13 Nov 2019
👀1

I pushed more changes last nigh and aspnetcore should build now as well. core-sdk builds if requested without dependencies after building at least up to core-setup prior.
Full source-build currently breaks on fsharp.
I'm not sure how much we care at the moment. It seems like getting just c# would be still useful.
Would it make sense to skip fsharp for now @crummel ?

wfurt picture wfurt on 14 Nov 2019

I don't know that we have the ability right now to skip F# entirely - I think toolset will try to bring it in as a prebuilt, so I think we might still run into issues with F# not having BSD bits available. If we can figure out a way to skip it for BSD only I'd be fine with that, we can disable the F# tests and prebuilt auditing on BSD if necessary.

crummel picture crummel on 14 Nov 2019

ok. I'll give it some try over the weekend. Back then when we had FreeBSD CI build we updated core-sdk not to expect asp.net and 2.1 runtime as it was not available. Conveniently, there was already some property for that. I don't remember anything about fsharp but we probably got prebuilt from Windows.

wfurt picture wfurt on 14 Nov 2019

Are there any dotnet repos with BSD CI running? It'd be good if we could get that set up.

crummel picture crummel on 14 Nov 2019

Maybe @brettfo can confirm, but by the looks of it, fsharp uses the similar scripts call order as corefx, so it might be possible to share some updated code from those scripts? i can give it shot (to make fsharp build) if that's worth the effort at this point @wfurt.

am11 picture am11 on 14 Nov 2019 
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'kernel32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Shared object "libkernel32.dll" not found, required by "dotnet" (TaskId:93)
11:12:46.265 13:43>CoreCompile: (TargetId:188)
                        at FSharp.Compiler.Lib.UnmanagedProcessExecutionOptions.GetProcessHeap() (TaskId:93)
                        at FSharp.Compiler.Lib.UnmanagedProcessExecutionOptions.EnableHeapTerminationOnCorruption() in /mnt/github/fsharp/src/fsharp/lib.fs:line 534 (TaskId:93)
                        at FSharp.Compiler.CommandLineMain.main(String[] argv) in /mnt/github/fsharp/src/fsharp/fscmain.fs:line 81 (TaskId:93)
11:12:46.471  18:6>Project "/mnt/github/fsharp/src/fsharp/FSharp.Compiler.nuget/Microsoft.FSharp.Compiler.csproj" (18:6) is building "/mnt/github/fsharp/src/fsharp/fsc/fsc.fsproj" (15:15) on node 1 (default targets).

I did not figure out how it works on OSX and Linux. fsharp repo seems to have almost no platform code and this chunk seems clearly Windows specific.

wfurt picture wfurt on 14 Nov 2019

maybe. But it works on OSX and Linux somehow or we avoid getting here.

wfurt picture wfurt on 14 Nov 2019

@am11 and @wfurt I think your assumption is correct and the version number check was only accidentally working on Linux. On an Ubuntu 18 box System.Environment.OSVersion.Version.Major is 4 and System.Environment.Version.Major is 3.

@am11 if you send a PR to dotnet/fsharp I'll try to do a quick review and merge, but I don't know how the submodule pointers get updated, maybe @crummel can answer that.

brettfo picture brettfo on 14 Nov 2019

You may be right @brettfo
On Ubuntu 16 I get 4.4.0.145 and that corresponds to kernel version from /proc/version.
However on OSX 10.14 I get 18.7.0.0 -> once again corresponds to kern.version

If we feel this is right change I can add patch to #1362

wfurt picture wfurt on 14 Nov 2019

There is also a HeapSetInformation condition after that one, maybe on macOS that is the one preventing the accidental call? would be nice if you could confirm whether the patch works. I have prepared a PR: https://github.com/dotnet/fsharp/pull/7858.

am11 picture am11 on 14 Nov 2019

With proposed change, fsharp builds for me. (quick test outside of source-build)

wfurt picture wfurt on 14 Nov 2019
🚀3 
[furt@daemon /mnt/github/source-build]$ time ./build.sh
...
...
...
ls-local/prebuilt-baseline-online.xml' [/mnt/github/source-build/repos/known-good.proj]
    2701 Warning(s)
    0 Error(s)

Time Elapsed 00:59:53.44

real    59m54.934s
user    52m7.936s
sys 21m48.115s    2701 Warning(s)
    0 Error(s)

I can finally build everything. I did hit some weird issues while trying to build various repos.
It turned out I was running of out memory and 4G is not enough. After moving to 8G in my VM build is more stable even if it still aborts randomly once in a while.

wfurt picture wfurt on 15 Nov 2019
👍5 🎉2

Are ASP.NET Core 3.0 apps supported? I'm trying to run a very basic ASP.NET Core app with just pre-built SDK/packages from this guide and getting the error:

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

Steps to reproduce:

$ mkdir web1
$ cd web1
$ ~/dotnet-sdk/dotnet new web
The template "ASP.NET Core Empty" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /usr/home/user1/web1/web1.csproj...
  Restore completed in 115.68 ms for /usr/home/user1/web1/web1.csproj.

Restore succeeded.

$ ~/dotnet-sdk/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
FeodorFitsner picture FeodorFitsner on 29 Nov 2019

did you publish packages and updated your nuget config? I don't think the bootstrap sdk had ASP.NET.

wfurt picture wfurt on 2 Dec 2019

I've tried that web app example with bootstrap SDK. So, in order to have ASP.NET Core packages I have to go through the entire build process from the article, i.e. bootstrap SDK has only minimum to build "normal" SDK, correct?

FeodorFitsner picture FeodorFitsner on 2 Dec 2019

yes, at least for now. The bootstrap @jasonpugsley put together is based on pre-3.0. If he (or somebody else) makes update, it would be possible to consume package directly without full build. I have not done any testing personally with ASP.NET. However I still should have my build somewhere. I can publish my packages if you want to give it try.

We may have enough now that it may be worth of crafting real package for ports collection.

wfurt picture wfurt on 2 Dec 2019

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

FeodorFitsner picture FeodorFitsner on 2 Dec 2019

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?

FeodorFitsner picture FeodorFitsner on 3 Dec 2019

@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. :)

am11 picture am11 on 3 Dec 2019

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.

wfurt picture wfurt on 3 Dec 2019

@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!

FeodorFitsner picture FeodorFitsner on 3 Dec 2019

@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.

am11 picture am11 on 3 Dec 2019

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

FeodorFitsner picture FeodorFitsner on 3 Dec 2019

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)

am11 picture am11 on 3 Dec 2019

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.

FeodorFitsner picture FeodorFitsner on 3 Dec 2019 
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
am11 picture am11 on 3 Dec 2019

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.

wfurt picture wfurt on 3 Dec 2019

@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?

FeodorFitsner picture FeodorFitsner on 4 Dec 2019

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

wfurt picture wfurt on 4 Dec 2019

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 picture FeodorFitsner on 4 Dec 2019

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.

FeodorFitsner picture FeodorFitsner on 4 Dec 2019

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.

wfurt picture wfurt on 4 Dec 2019

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

FeodorFitsner picture FeodorFitsner on 4 Dec 2019

@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
FeodorFitsner picture FeodorFitsner on 4 Dec 2019

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 picture wfurt on 4 Dec 2019

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 picture wfurt on 4 Dec 2019

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 ?

wfurt picture wfurt on 5 Dec 2019

@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).

am11 picture am11 on 5 Dec 2019

@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?

FeodorFitsner picture FeodorFitsner on 5 Dec 2019

@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?

jasonpugsley picture jasonpugsley on 5 Dec 2019

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 picture am11 on 5 Dec 2019

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.

am11 picture am11 on 5 Dec 2019

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 picture wfurt on 5 Dec 2019

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)

wfurt picture wfurt on 5 Dec 2019

@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.

jasonpugsley picture jasonpugsley on 5 Dec 2019

@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?

FeodorFitsner picture FeodorFitsner on 5 Dec 2019

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

wfurt picture wfurt on 5 Dec 2019

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

crummel picture crummel on 5 Dec 2019

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.

crummel picture crummel on 5 Dec 2019
👍1

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.

wfurt picture wfurt on 10 Dec 2019

@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.

am11 picture am11 on 10 Dec 2019
👍2

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?

trasz picture trasz on 16 Dec 2019

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.

wfurt picture wfurt on 16 Dec 2019

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?

ghost picture ghost on 27 Jan 2020
👍4

@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.

joperator picture joperator on 28 Feb 2020

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

danmoseley picture danmoseley on 28 Feb 2020

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.

jasonpugsley picture jasonpugsley on 19 Apr 2020

@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!

FeodorFitsner picture FeodorFitsner on 20 Apr 2020
👍2

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 picture wfurt on 20 Apr 2020
👍2

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 picture wfurt on 20 Apr 2020

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 picture wfurt on 20 Apr 2020

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.

wfurt picture wfurt on 20 Apr 2020

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 picture jasonpugsley on 20 Apr 2020
🎉3

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

jasonpugsley picture jasonpugsley on 24 Apr 2020
👍3 🚀1

@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! 🎉

FeodorFitsner picture FeodorFitsner on 26 Apr 2020
👍5

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

jasonpugsley picture jasonpugsley on 6 May 2020
👍1

@jasonpugsley Thank you! Will give it a try this week and let you know.

FeodorFitsner picture FeodorFitsner on 6 May 2020

Building via @jasonpugsley guide fails in a FreeBSD 11.3 jail with
Failed to create CoreCLR, HRESULT: 0x8007001F
ERROR: An error occurred in /usr/home/build/src/coreclr/.dotnet/dotnet restore /nologo /verbosity:minimal /clp:Summary /m /home/build/src/coreclr/src/.nuget/optdata/optdata.csproj /p:__BuildArch=x64 /p:__BuildType=Release /p:__BuildOS=FreeBSD /nodeReuse:false /p:RestoreDuringBuild=true /v:detailed /p:PortableBuild=false /p:OfficialBuildId=20200218.3 /p:ContinuousIntegrationBuild=true /p:PortableBuild=true. Check logs under /home/build/src/coreclr.

I does not generate any logs either.
The best I can tell (from someone else with a build similar issue on MacOSX) is that its an mlock() issue or having only 18G free of RAM when ZFS cache is eating over 320G might be an issue

Thefrank picture Thefrank on 7 May 2020

I haven't used jails but I have come across the mlock issue myself on another freebsd based system so it could be what's going on here. The failure occurred when it allocated 4096 bytes and then tried to mlock() that memory mprotect that memory with PROT_NONE, it failed with EPERM EACCESS. I didn't get a chance to look any further. Sorry, ignore all that. It doesn't apply to vanilla FreeBSD.

Everything I've done here has been using a vanilla FreeBSD 11.3 install in a fully virtualised VM.

jasonpugsley picture jasonpugsley on 7 May 2020

@wfurt what do you all need to make FreeBSD an official platform at this point? There's no possible way I can bring this current process into ports. And that is the direction that I would like to take things on the FreeBSD side.

rootwyrm picture rootwyrm on 20 May 2020
❤1

I'm afraid some of it is not technical. We would need to convince product owners it is worth it. It is not just the code base but also infrastructure and support commitments. Adding CI leg to prevent build regressions was best I could do so far.
We've been progressing on independent build with @am11 with the intention to produce rolling builds, packages and test runs. I think it is unlikely there will be official FreeBSD support in .NET 5 so I was thinking about some form of community effort.
I think targeting ports is right direction. Maybe we can brainstorm via chat or call what would need to be done for the ports, and perhaps bring specific issues back here. The source-build exist with the intention that distro owners could incorporate it to their package builds and be independent of MS binaries.

wfurt picture wfurt on 20 May 2020

Totally aware of the political aspects of it, which is what I'm asking about. Unfortunately I'm also painfully well aware that's going to be an uphill battle to an extent due to the current state of the (Microsoft owned and maintained) FreeBSD Azure images.

The problem here is that there is absolutely no possible way the current method can be put into ports due to the SDK binary elements that are still required. That creates a hard blocking legal issue.

Definitely up for some brainstorming to see what we can do to sell the product owners on it. What's the best platform for you?

rootwyrm picture rootwyrm on 20 May 2020

The problem here is that there is absolutely no possible way the current method can be put into ports due to the SDK binary elements that are still required. That creates a hard blocking legal issue.

I am a Linux guy, so maybe I am missing something, but we have similar restrictions in Free-focused linux distributions like Fedora. source-build has let us work around all that:

  1. We used an initial set of prebuilt (compilers, runtime, packages) binaries in our packages. This is similar to bootstrapping any other language. I hope even FreeBSD allows for that.

  2. We then used the prebuilt binaires to build source-build within Fedora.

  3. Then we threw away the prebuilt binaires and used the just-built source-build to bulid source-build again.

Now we have a working .NET Core SDK (based on source-build) which works without requiring prebuilt SDK (or other) binaries. End users (folks consuming Fedora packages) still need to fetch things from nuget to build their own applications, of course.

Is a workflow like this suitable for FreeBSD ports? If not, can you help us understand what else source-build needs to do?

omajid picture omajid on 21 May 2020
👍3

@omajid this is a false equivalence because you have legally available, legitimate SDK binaries direct from Microsoft. FreeBSD does not any longer and has no way to bootstrap. A random OneDrive link to retracted binaries is not a legitimate source. The only way any of this can legally go into ports in any form (which is _still_ going to be months of arguing) is with official SDK blobs either 'officially supported' or 'as-is' officially published by Microsoft.

rootwyrm picture rootwyrm on 21 May 2020
👍1

as-is _may_ be doable via https://github.com/dotnet/runtime/issues/35609

wfurt picture wfurt on 21 May 2020

has no way to bootstrap.

Here are the self-dependent bootstrapping steps for 5.0 in the form of shell script, which are running on public CI: https://github.com/wfurt/freebsd-bootstrap-cli/blob/428905/.cirrus.yml.

We required the real Linux VM because Linux emulation on FreeBSD failed to execute some syscalls made by dotnet(1) (membarrier etc.), among other mechanical glitches like missing ca certificates in base chroot to make the initial curl call by shell scripts in dotnet/runtime (FreeBSD bugzilla has issues opened for these two).

I think if Microsoft's CI in this repo (or dotnet/runtime && dotnet/sdk?) can ensure that these bootstrapping steps are maintained, any (not officially supported) platforms can reliably depend on them. The chances of these steps getting staled/broken are approximately once a week, whenever PRs from app/dotnet-maestro are merged in dotnet/sdk or dotnet/runtime repos.

am11 picture am11 on 21 May 2020
👍2

Thanks, @rootwyrm . I didn't realize that the issues were about the source of the bootstrap SDK (and other binaries).

For my own understanding, is there any guidance on how "authoritative" that source needs to be? Would it need to be Microsoft, the company? Could it be a developer working on .NET but paid by Microsoft? What if it's a developer who works on .NET but paid by $ANOTHER_COMPANY? What about a person who contribute to .NET on their own free time?

Edit: and a question about "legally": is this about the license of the binaries? Does .NET core being open source not satisfy some legal requirement? I am not sure what this part here means:

this can legally go into ports in any form

omajid picture omajid on 21 May 2020

as-is may be doable via dotnet/runtime#35609

@wfurt I'll have to take a look; if they're actually providing the seed binaries required to bootstrap. Those are the hard blockers. 'Anything goes' NuGet is already in the tree (albeit broken as hell, and not likely to be fixed before 2022 at this rate.) Once we have either seed or SDK binaries (either-or) it's one of those 'hopefully a few days' things as opposed to 'check back in 6 months.' Aside from actually getting it committed, or finding those few days.

For my own understanding, is there any guidance on how "authoritative" that source needs to be? Would it need to be Microsoft, the company? Could it be a developer working on .NET but paid by Microsoft? What if it's a developer who works on .NET but paid by $ANOTHER_COMPANY? What about a person who contribute to .NET on their own free time?

For legal and security reasons, it always _MUST_ be the original author, followed by an explicitly or implicitly authorized mirror as an optional alternate. Any other source is an automatic 'no-no' because there is no possible way to ascertain whether or not there are modifications or it is in compliance with the code's licensing.
Using Mono as an example, Mono is MIT licensed. This means that FreeBSD can redistribute binary packages of it (so a non-RESTRICTED port.) However, I cannot just re-host a tarball that the Mono team retracted and call it good. Or my personal tarball that has a bunch of patches applied. It has to originate from the official main distribution site, and be confirmed against the MD5/SHA/signature of the original file, and patches must apply against those files.

In the case of the SDK and/or seed binaries (specifically referring to dotnet.microsoft.com/download/), the license is not explicitly open and redistribution is clearly prohibited, similar to portions of Java. And this extends to any linked in components (e.g. CoreLib, assemblies, etcetera.) These essentially taint the port's license.
The other problem at this point is that the entire method as it sits just cannot work within the ports infrastructure. (Which I'm sure @wfurt is thrilled to hear.) Things like "set your system timezone to UTC" and "requires python27" are automatic deal-breakers, even before we get to "download things in the middle of the build" (which is a whole thing.) Especially python27.

rootwyrm picture rootwyrm on 21 May 2020

Why don't you contact me at me GH address tweinfurt at yahoo. We can find channel to have conversation and bring back specific issues @rootwyrm

wfurt picture wfurt on 21 May 2020

Thanks @rootwyrm , but now I have another set of questions. Thanks again for putting up with me.

Using Mono as an example, Mono is MIT licensed. This means that FreeBSD can redistribute binary packages of it (so a non-RESTRICTED port.) However, I cannot just re-host a tarball that the Mono team retracted and call it good.

This is about a binary SDK release, right?

Or my personal tarball that has a bunch of patches applied. It has to originate from the official main distribution site, and be confirmed against the MD5/SHA/signature of the original file, and patches must apply against those files.

But this is about source tarball? If so, then this might be another action item for source-build. Right now, source-build does not publish releases. They tag things in the git tree. That's not acceptable, is it? Or would signed git tags be acceptable?

In the case of the SDK and/or seed binaries (specifically referring to dotnet.microsoft.com/download/), the license is not explicitly open and redistribution is clearly prohibited, similar to portions of Java.

Hm. I (on behalf of Red Hat) have worked with folks at Microsoft to fix this this. My understanding was everything is explicitly open source for non-Windows now. For example, I just downloaded https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.1.300-linux-x64-binaries and checked out the LICENSE and ThirdPartyNotices.txt files. Every license looked open source to me.

Do you see anything different on your end? I think we can/should fix those issues.

And this extends to any linked in components (e.g. CoreLib, assemblies, etcetera.) These essentially taint the port's license.

Can you enumerate these? I am not sure these issues still exist. Source-build has (or at least was supposed to) fix them all. If there's stuff here that's not open source, that would affect us in Fedora as well, which only packages open source code.

omajid picture omajid on 22 May 2020

Things like ... "requires python27" are automatic deal-breakers

Can you please file bugs if python 3 doesn't work? I am running without python 2 here. Everything (including coreclr) should support python3 out of the box now. For example:

omajid picture omajid on 22 May 2020

~I haven't used jails but I have come across the mlock issue myself on another freebsd based system so it could be what's going on here. The failure occurred when it allocated 4096 bytes and then tried to mlock() that memory mprotect that memory with PROT_NONE, it failed with EPERM EACCESS. I didn't get a chance to look any further.~ Sorry, ignore all that. It doesn't apply to vanilla FreeBSD.

Everything I've done here has been using a vanilla FreeBSD 11.3 install in a fully virtualised VM.

took me a month but I found free time (aka 10 minutes of not being lazy) to get a FreeBSD VM setup under Hyper-V. builds perfectly!
edit: looks like im missing a dotnet-runtime-3.1.3-freebsd-x64.tar.gz that is needed from aspcorenet onward
edit2: nm I got it, never try to build an sdk when sleepy

Thanks for all the work!

Thefrank picture Thefrank on 5 Jun 2020

dotNET preview 5 builds (after linux bootstrap) on FreeBSD

Totally off topic bit:
I also took a deep dive on my issue with the dotnet binary failing in a jail.
It was not jail related. It was actually because of an issue that is isolated to only FreeNAS as it was fixed more than a year ago upstream on FreeBSD
https://jira.ixsystems.com/browse/NAS-106193
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145846+0+archive/2019/svn-src-head/20190519.svn-src-head

Summary: SDK that now builds under FreeBSD (after linux bootstrap). If you want your binary to work in FreeNAS you will have to wait until the upstream solution is merged.

Thefrank picture Thefrank on 16 Jun 2020
👍2

@jasonpugsley any tips for getting aspnetcore to build on dotnet 5 previews? Nuget seems to be mismatching the runtime I built

week later edit: aspnetcore builds only with /p:CrossgenOutput=false (and me not being an idiot when generating runtimecore)

Thefrank picture Thefrank on 20 Jun 2020

Hi, where can I download dotnet-runtime-3.1.3-freebsd-x64.tar.gz
Salve, scusate dove posso scaricare il file dotnet-runtime-3.1.3-freebsd-x64.tar.gz

bluff78 picture bluff78 on 4 Nov 2020

Wow, that is a lot of intensive Q/A. Super!

I understand that we can run .NET in Linux in a Bhyve container environment with FreeBSD - perhaps it might serve to support some web app tests, at least, e.g with the reverse proxy server running on a FreeBSD host? Not to just blog about it here, I'm certainly interested in helping out this porting process, for .NET support on FreeBSD. Albeit I wonder if I might be in a little over my depth, right now, with the syscall concerns and then so many moving parts in the build process.

I wonder, Are there any ideas for how the build process might change in .NET 6? I understand that there's .NET MAUI support being proposed for that framework/platform release, candidly I'm not familiar with much else about that SDK major version however. (Off topic, wondering if there will be any changes in Entity Framework, circa .NET 6 - no single ideas for it though, just noticing the fork to EF Core)

I will try to take a look at this lot of existing work, once the yearly port upgrade finishes. After looking at AvaloniaUI and some other things with VS 2019 on Windows 10 now, definitely interested in helping out for FreeBSD support for this accessible software development platform and .NET under .NET Core. Really impressed with how FreeBSD does I/O and the process scheduling in the kernel. imo .NET Core support on FreeBSD would be stellar, maybe it could be of interest to NetBSD and pkgsrc projects too.

spchamp picture spchamp on 16 Mar 2021

.NET 5 bootstraps/crossbuilds from Linux to FreeBSD with minor changes. That package can be used for further building of .NET 5 releases natively under FreeBSD with different minor changes it also produces working native FreeBSD binaries of programs built with -r freebsd-x64. Some require major changes like Azure Pipelines Agent others build with no changes like jellyfin.

.NET 6 preview bootstraps/crossbuilds from Linux to FreeBSD with minor changes. Currently that package is unable to build natively under FreeBSD

Thefrank picture Thefrank on 16 Mar 2021
👍1

.NET 5 bootstraps/crossbuilds from Linux to FreeBSD with minor changes. That package can be used for further building of .NET 5 releases natively under FreeBSD with different minor changes it also produces working native FreeBSD binaries of programs built with -r freebsd-x64. Some require major changes like Azure Pipelines Agent others build with no changes like jellyfin.

.NET 6 preview bootstraps/crossbuilds from Linux to FreeBSD with minor changes. Currently that package is unable to build natively under FreeBSD

Stupid question - is this somewhere documented, how to (cross)build .NET 5 for FreeBSD?

sec picture sec on 21 Apr 2021
👍1

I look at runtime docs @sec and some is still very old written by @josteink years ago. The official build is using docker image to make it easier but once and create it locally using build-rootfs.sh and esentially run build with -cross -os FreeBSD -clang9 I can dig out more details about various parts if anybody wants to put some effort to docs.

I'm also going to post some more notes to main runtime issue

wfurt picture wfurt on 21 Apr 2021
👍2

https://github.com/Thefrank/dotnet-freebsd-crossbuild ? That is what I use to get started

That script should cover building runtime, aspnetcore, and packaging into installer

TODO: Using said product natively under FreeBSD. It requires patches and/or work arounds that I have no been able to condense into a script yet.

hattip: @ta264

Thefrank picture Thefrank on 21 Apr 2021
👍1

@wfurt @Thefrank
Using https://github.com/Thefrank/dotnet-freebsd-crossbuild I was able to compile .NET 5 on fresh Linux machine (there was one error with path to patch, download problems, nothing major), but in the end I got the SDK. I took the packages from both aspnetcore and runtime artifacts dir, SDK from installer artifacts, put those on fresh FreeBSD 13 machine (according to https://github.com/jasonpugsley/installer/wiki/.NET-Core-3.1.103-for-FreeBSD) and tried, almost worked:

/usr/home/sec/dotnet5/sdk/5.0.202/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(99,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'freebsd-x64'.

What I missed?

Worth to mention that SDK from https://github.com/jasonpugsley/installer/wiki/.NET-5.0-Preview-3-for-FreeBSD works fine on the same BSD box (simple MVC webapp with EF Core + Sqlite).

sec@hyperv:~ % dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.202
 Commit:    db7cc87d51

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  13
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/sec/dotnet5/sdk/5.0.202/

Host (useful for support):
  Version: 5.0.5
  Commit:  2f740adc14

.NET SDKs installed:
  5.0.202 [/usr/home/sec/dotnet5/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.5 [/usr/home/sec/dotnet5/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/home/sec/dotnet5/shared/Microsoft.NETCore.App]

Output from 5 preview build has diffrent RID: freebsd.13-x64, but according to RuntimeIdentifierGraph.json this should be fine, so my best bet is that something minor is missing.

Another stupid questions - assuming SDK will work - how to execute test suite for it on BSD box?

sec picture sec on 23 Apr 2021

@sec the missing host thing likely came from one of the sed hacks in the installer step failing.

In your specific case this should resolve it:
sed -i.ORI 's/osx-x64/osx-x64;freebsd-x64/' /usr/home/sec/dotnet5/sdk/5.0.202/Microsoft.NETCoreSdk.BundledVersions.props

do you have the build error(s) that were generated? That should help me figure out what went wrong.

As for the RID being different, the preview ones patch in full FreeBSD version numbers...which, because FreeBSD has a nice symbol versioning feature, really should be used.

Thefrank picture Thefrank on 23 Apr 2021

@Thefrank Thanks, that replace did the thing - I was greping json files and missed that one :)
So now I have .NET 5.0.5 working on FreeBSD, "yay" :)

The errors during crossbuild on Linxu machine were:

As for the sed, I saw it's included in your build script - I will run the whole thing from start and check why it failed - maybe I took the file from wrong directory or something - is there any "packer" to grab all the needed output and produce a nice set of "dotnet" things or just a simple cp will to the trick (just like I did by hand, dunno know if I missed anything, though) ?

And what would be the next step in getting this to compile on bsd box?
And can't this output be used to help in getting bsd build "somewhere" "semi-official"? :)
And if could point me to some direction on how to run test suite for .net/aspnetcore directly on bsd box - I assume I can use the build I just produced?

sec picture sec on 26 Apr 2021
🎉2

download errors

Those seem pretty random but I always assumed they were on my end but I guess other people get those too. No idea what is going on there :(

typo

I will get that fixed ASAP!

The sed lines in the installer segment manually patch in support for FreeBSD into the SDK when it gets bundled. Something may have changed in the files to cause one or both of those to fail hence the missing support.

As for a packer: the installer repo is what creates a full working, bundled dotNET SDK. Check in ./installer/artifacts and there should be an SDK in both tar.gz and zip

For compiling under FreeBSD take a look the work being done here: https://github.com/dotnet/runtime/issues/14537

Thefrank picture Thefrank on 26 Apr 2021

download errors

Those seem pretty random but I always assumed they were on my end but I guess other people get those too. No idea what is going on there :(

typo

I will get that fixed ASAP!

For me git -C installer apply ../patches/0001-freebsd-support.patch worked

The sed lines in the installer segment manually patch in support for FreeBSD into the SDK when it gets bundled. Something may have changed in the files to cause one or both of those to fail hence the missing support.

I will check the logs after build complete and check why it's not there.

As for a packer: the installer repo is what creates a full working, bundled dotNET SDK. Check in ./installer/artifacts and there should be an SDK in both tar.gz and zip

Yes I saw those, but those don't include the nuget packages that needs to be put into local feed (or I just missed them).

For compiling under FreeBSD take a look the work being done here: dotnet/runtime#14537

I'm been reading/writing in that thread for the last 5 years :) it's a bit out-of-date now, as building chain changed from what I saw and I'm trying to get back into that, but either I'm can't search for docs or just can't find a clean howto the whole process works :) I saw https://github.com/wfurt/freebsd-bootstrap-cli which I plan to check in coming days

sec picture sec on 26 Apr 2021

oh! if you use Azure DevOP you can checkout https://github.com/Servarr/dotnet-bsd as an Azure version of Shell script.

The releases also include the nuget packages that are required for either building under FreeBSD or building to FreeBSD. The same sed script that I gave you for your SDK error will add support for FreeBSD to any working SDK as long as you provide the nuget packages in your own feed.

The advantage is that it uses all the nice Azure reporting and it might be more familiar to people. Anything that requires native testing will still require a FreeBSD VM but all of the building can be done under your preferred OS.

Thefrank picture Thefrank on 26 Apr 2021

@Thefrank I also saw this, thanks.
My point is that, at the moment I did the cross-compile under Linux to FreeBSD, prepared nuget packages from aspnetcore and runtimes artifcats by hand, took sdk from artifacts, put this into bsd box and it's working fine - thanks to your scripts :)

Question to that part was, is there an archive with those nuget's produced by installer, as I only saw SDK and runtime (I assume they are pushed later into official feed, but for FreeBSD we're not there yet, that's why we need to have them locally with correct RID's etc inside, right?).

Now what I would like to know next, is how to start building native this under bsd box and/or run tests under bsd box, to see what is failing etc. That's the same discussion as in https://github.com/dotnet/runtime/issues/14537 - just trying to read/find the correct docs about building process of .net core etc.

sec picture sec on 26 Apr 2021

SDKs don't include NuGet packages. dotNET/NuGet gets those packages during restore by looking both locally and from feeds provided to it.

for building programs you will need the following packages:

from runtime:

Microsoft.NETCore.App.Host.freebsd-x64.5.0.5.nupkg
Microsoft.NETCore.App.Runtime.freebsd-x64.5.0.5.nupkg

and from ASPNetCore:

Microsoft.AspNetCore.App.Runtime.freebsd-x64.5.0.5.nupkg

as for native builds you will need a seed SDK (like the one you just built) and various patches different patches to cover things like bad linker detection, crossgen2 issues, and inconsistent version numbering. jasonpugsley (https://github.com/dotnet/runtime/issues/14537#issuecomment-826650762) has done a good job of combining the patches needed to build runtime natively. it should also pass all of the tests...you may have to install ncurses for the console tests to pass...that might also require a patch too...its been a while :(

ASPNetCore requires fewer patches but sadly has test failures. On the plus they mostly seem seem libuv related and that has been dropped for dotNET6+

Finally, wfurt is looking for volunteers! https://github.com/dotnet/runtime/issues/14537#issuecomment-824248881

edit: hopefully that answered your question!

Thefrank picture Thefrank on 27 Apr 2021

Hey,
It's betting more and more clear :) I think I just need to read/find more docs etc., but that's already good start.
For the things that were failing - here's a patch for 2 lines that fixes both errors I've had https://gist.github.com/sec/ce64d033399ad96a2617d4c358b1adba

Again thanks for help @Thefrank :)

If I'm not wrong, the same thing could apply to patches in https://github.com/Servarr/dotnet-bsd @ta264

@joperator do you think this issue is still valid to be open?

sec picture sec on 27 Apr 2021

@sec thanks for the patch! I added it and updated some info in the README.md to make things (hopefully) a bit more clear

Thefrank picture Thefrank on 27 Apr 2021

@joperator do you think this issue is still valid to be open?

@sec Yes, because there is still no official and especially up-to-date documentation on how to build the .NET Core SDK on FreeBSD:
The Developer Guide for dotnet/sdk does not mention FreeBSD at all and the Requirements to build dotnet/runtime on FreeBSD are outdated. Current instructions are scattered across multiple repos, issues, and comments, making it difficult, especially for new developers, to find a good starting point on how to build .NET 5, 6, and future versions on FreeBSD.

joperator picture joperator on 28 Apr 2021

I look at runtime docs @sec and some is still very old written by @josteink years ago. The official build is using docker image to make it easier but once and create it locally using build-rootfs.sh and esentially run build with -cross -os FreeBSD -clang9 I can dig out more details about various parts if anybody wants to put some effort to docs.

I'm also going to post some more notes to main runtime issue

Glad someone asked, tbt. Finally getting back around to this now ... imo, the mention of documentation, it may seem to remind of the FreeBSD Documentation Project (in all of its DocBook formalism).

I'd guess Markdown works, too? Not in regards to formats so much, I wonder: Pursuant of any more interest in the topic, may it be possible for anyone - perhaps, anyone more familiar with the build process and the framework itself - to contact the FreeBSD mailing lists if not the FreeBSD Fdn itself, if it may be possible for to assign a mailing list to the topic? Not only for the heavy use of LLVM in the .NET build and throughout the FreeBSD base system, too, perhaps there may be any intersectional interests for .NET and "FreeBSD Core" broadly (??) Of course, I'm just kind of guessing here - understanding, I'm not a formal representative of .NET or FreeBSD.

Personally, I've not ever worked on a group documentation project, though I'm familiar with DocBook 4 and DocBook 5. Insofar as for the .NET Core build,itself, I'll try to get my own notes together and try to produce a build. I'm using a local FreeBSD 11.2 build - still in the process of upgrading it tbt - with a particular src.conf and such that it's used principally for ports build, local make.conf. Unpublished, it might be controversial in some local decisions for the build config. It works tho ...

Perhaps something like one of the formal FreeBSD documentation docs could be of help, at some future time?

Health, all

-- Sean

spchamp picture spchamp on 21 May 2021
Was this page helpful?
0 / 5 - 0 ratings

Related issues

omajid picture omajid  ·  8Comments
crummel picture crummel  ·  9Comments
eerhardt picture eerhardt  ·  8Comments
omajid picture omajid  ·  5Comments
dagood picture dagood  ·  6Comments