Runtime: Support for FreeBSD

There seems to be agreement as far as https://github.com/dotnet/corefx/issues/1576 is concerned.

When we also have a decision on https://github.com/dotnet/corefx/issues/1625 we should be able to start shipping some code.

Agreement on dotnet/runtime#14536 has been reached by the portteam, unless MSFT chooses otherwise it will be FreeBSD. Issue dotnet/corefx#1999 will potentially be the issue that introduces the definition into the public API.

Agreement on dotnet/runtime#14536 has been reached by the portteam, unless MSFT chooses otherwise it will be FreeBSD

If I read that right, this means that when https://github.com/dotnet/corefx/pull/1999 is merged, we can consider this MSFT approving of the new public API, and can therefore press forward on the remaining issues with regular pull-requests without need for MSFT approval.

If so, that sounds good to me.

Next steps as per https://github.com/dotnet/corefx/pull/1999#issuecomment-111279577 are:

1. The "FreeBSD port team" continues their work to get a FreeBSD version of CoreFX produced (tracked by dotnet/corefx#1626).
2. The port team brings up enough of the CoreFX and CoreCLR stack on FreeBSD such that we can start running the CoreFX unit tests on FreeBSD.
3. The tests reach some minimal quality level. I don't know exactly what this looks like yet, but I expect it means something like a majority of the tests pass. Ideally we would not have a bunch of specific tests disabled for only FreeBSD (compared to Linux and OSX, we wouldn't want to hold FreeBSD to a higher standard than the other *NIX platforms we have there).
4. Working with the FreeBSD port team, the CoreFX team gets the CoreFX tests added to our CI system running on FreeBSD.
5. Discuss merging a PR based for issue dotnet/runtime#14536, which adds the property.

That sounds like a fully reasonable plan to me.

Okay, then let's start the work on getting corefx to work.

First obstacle in building corefx on FreeBSD seems to be mono. The build-script insists version 4.1 is required. @ajensenwaud did some work on this on the Frankfurt-host, but I'm not sure how complete it is.

I'll queue a build for now and see what the output looks like.

Edit: The (mono) build crashes with the following kicker at the end:

Making all in mini
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2906: warning: duplicate script for target "%.exe" ignored
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2899: warning: using previous script for "%.exe" defined here
  CC       genmdesc-genmdesc.o
In file included from genmdesc.c:9:0:
mini.h:17:34: fatal error: ./mono/metadata/loader.h: Too many levels of symbolic links
 #include <mono/metadata/loader.h>
                                  ^
compilation terminated.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/josteink/mono/mono/mini
*** Error code 1

Stop.

First obstacle in building corefx on FreeBSD seems to be mono

FWIW, I personally don't think this is the first obstacle. There are two build related issues:

1. Building assemblies that work correctly on FreeBSD
2. Building those assemblies on FreeBSD

(1) is critical, and is I believe what this issue is meant to be about. (2) is very nice to have, but lack of it doesn't prevent the creation of a great system for running managed code on FreeBSD.

You're of course free to prioritize however you see fit, but my recommendation would be to focus on (1) rather than (2).

Note that we still have issues building corefx on Linux and building it on OSX, such that our CI system builds the assemblies for those platforms on Windows; it then shuttles the resulting assemblies over to the target platform to execute the tests.

That's fair enough. I just assumed that it would be easier to get general FreeBSD platform support baked into corefx if we could actually build it ourselves on FreeBSD.

I'll make do with Windows-initiated building for now and attempt to ninja together a build-configuration.

@josteink btw. corefx should now build on Mono 4.0.1.44.

@akoeplinger Nice. That leaves me some hope we can get it running on FreeBSD too :)

Good points. However if we really want corefx to be part of the FreeBSD environment, we really need it to be able to compile from source to get it into the Ports system.

I did hear that Mono 4.0.1.44 fixes a lot of these issues but have not had time to play with it yet. I know the ports team are updating the port Makefile as well as we speak with a new patch.

On 12 Jun 2015, at 20:21, Stephen Toub [email protected] wrote:

First obstacle in building corefx on FreeBSD seems to be mono

FWIW, I personally don't think this is the first obstacle. There are two build related issues:

Building assemblies that work correctly on FreeBSD
Building those assemblies on FreeBSD
(1) is critical, and is I believe what this issue is meant to be about. (2) is very nice to have, but lack of it doesn't prevent the creation of a great system for running managed code on FreeBSD.

You're of course free to prioritize however you see fit, but my recommendation would be to focus on (1) rather than (2).

Note that we barely have corefx building-on-Linux and building-on-OSX, such that our CI system builds the assemblies for those platforms on Windows; it then shuttles the resulting assemblies over to the target platform to execute the tests.

—
Reply to this email directly or view it on GitHub.

Yes, I'm in no way disagreeing... being able to _build_ corefx on Linux, OSX, and FreeBSD is important. I'm simply suggesting that from a priority perspective it's more important to be able to actually _run_ corefx on Linux, OSX, and FreeBSD. :wink: If both can be worked on in parallel, all the better.

@ghuntley,
would be super :cool: if we have a markdown task checklist outlining what what is remaining:

- [x] task 1
- [ ] task 2
- [ ] task 3

renders as:

• [ ] task 1
• [ ] task 2
• [ ] task 3

This will probably encourage others to score those feats and FreeBSD support will land rather sooner than anticipated! :sunglasses:

To my knowledge the following pieces of work in CoreFX are required for FreeBSD support:

• [x] Introduce FreeBSD platform to the build tools and scripts. (Done by @josteink and me, PRs dotnet/corefx#2021 merged, dotnet/corefx#2030 merged)

13 Assemblies do not compile on their own and need FreeBSD specific changes. Mostly the Interop pieces that already exist for Linux/OS X (order by the occurrence in the build output):

• [x] System.Private.URI (done, PR dotnet/corefx#2032 merged)
• [x] System.Console (done, PR dotnet/corefx#2031 merged)
• [x] System.Diagnostics.Debug (done, PR dotnet/corefx#2039 merged)
• [x] System.Diagnostics.Process (discussion dotnet/corefx#2070, PR dotnet/corefx#3257)
• [x] System.IO.Compression.ZipFile (done, PR dotnet/corefx#2041 merged)
• [x] System.IO.FileSystem.DriveInfo (discussion dotnet/corefx#2526, PR dotnet/corefx#2606)
• [x] System.IO.FileSystem.Watcher (discussion dotnet/corefx#2046, PR dotnet/corefx#3257)
• [x] System.IO.FileSystem (done, PR dotnet/corefx#2049 merged)
• [x] System.IO.MemoryMappedFiles (discussion dotnet/corefx#2527, PR dotnet/corefx#3143)
• [x] System.IO.Pipes (discussion dotnet/corefx#2528, PR dotnet/corefx#2974)
• [x] System.Net.NameResolution (discussion dotnet/corefx#2988, PR dotnet/corefx#3471)
• [x] System.Security.Cryptography.Hashing.Algorithms (done, PR dotnet/corefx#2040 merged)
• [x] System.Security.SecureString (done, PR dotnet/corefx#2039 merged)
• [x] System.Runtime.Environment (blocked by dotnet/corefx#1999 )
• [x] System.Runtime.InteropServices.RuntimInformation (done, PR dotnet/corefx#2068 merged)

I will try to update that list based on PRs opened and merged.

FYI: PR dotnet/corefx#2039 merged

Just trying to be ahead of the curve here... How do we plan to implement System.IO.FileSystem.Watcher ?

Iirc FreeBSD has no inotify such as Linux and Windows does (which is also why there is no Dropbox last time I checked). Will this be a potential source of trouble coming our way? Or does anyone have an idea for how to work around this?

I suggest we stub that out for the moment and throw a PlatformNotSupportedException as Stephen Toub suggested in the other topic (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Then we have at least a complete set of assemblies and we can continue to work on that particular issue without blocking further steps.

Would you mind opening a separate issue for that?

Let's move System.IO.FileSystem.Watcher discussions to dotnet/corefx#2046

Guys is there any such blocker for System.Diagnostics.Process?

@jasonwilliams200OK added FreeBSD to S.RT.I.RI early this morning which was merged but the FreeBSD tests within CheckPlatformTests had to be backed out until dotnet/buildtools is updated.

• [ ] Update build tools to support FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [ ] Reapply [Fact,PlatformSpecific(PlatformID.FreeBSD)] tests to CheckPlatformTests - see https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 and https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [ ] Add public static OSPlatform FreeBSD to https://github.com/dotnet/corefx/pull/2068

@jasonwilliams200OK there were some discussions last night about System.Diagnostics.Process in gitter which have been formalized into https://github.com/dotnet/corefx/issues/2070

@ghuntley, thanks. I actually read those messages. System.Diagnostics.Process is a tricky one. AFAIK, io.js team had similar challenges with FreeBSD process management. Mono team has probably nailed it, so lets hope if @akoeplinger and co. could enlighten us on this matter? :)

System.IO.FileSystem.DriveInfo

As discussed in the gitter, For this one I tried looking into basic usage of getmntinfo:

#include <sys/param.h>
#include <sys/ucred.h>
#include <sys/mount.h>
#include <stdio.h>

int main() {
  struct statfs *mntbuf;
  int mntsize = getmntinfo(&mntbuf, MNT_NOWAIT);

  for( int i = 0; i < mntsize; i++ ) {
    printf("%s\n", mntbuf[i].f_mntonname);
  }
}

Running that sample yielded this output:

$ ./a.out
/
/dev
/tmp
/usr/home
/usr/ports
/usr/src
/var/crash
/var/log
/var/mail
/var/tmp
/dev/fd
/usr/compat/linux/proc
/proc
$

So it seems it does what we need. The question is, should we do any type of filtering on the results?

Looking at the "intent" of the DriveInfo object, coming from the Windows world of .NET it has often been to enumerate the available locations to store or retrieve files (C:, D:, etc). But when using Unix hierarchical file-systems, returning / would be adequate to cover those needs.

So what should we return? What would be useful? Should even consider it being useful or not?

The Linux-version just dumps everything, except things set to be ignored:

https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem.DriveInfo/src/System/IO/DriveInfo.Linux.cs#L98-L99

I tried putting in the following filter, but it didn't really change anything in terms of output:

    if ((mntbuf[i].f_flags != MNT_IGNORE)) {
        printf("%s\n", mntbuf[i].f_mntonname);
    }

Any opinions?

@josteink, great diggings! Based on https://github.com/dotnet/corefx/issues/815#issuecomment-113825960 and https://github.com/dotnet/corefx/issues/1729, I think we should collaborate with @sokket to come up with a solution with works across different Unices.

I have a version running on OSX that uses getmntinfo and statfs to get information about each mount point, which seems like the most logical mapping from the Windows Drive concept. I'll double check that the function and struct definitions on OSX match the FreeBSD definitions and, if so, my commit for OSX will work for BSD as well.

I'll be sure to add you to my PR @josteink

Sounds good. Thanks for the heads up and thanks for giving FreeBSD some love too.

I looked into some basic pinvoke for these functions, and it seems like we need to do all the marshalling and conversions ourselves, so if anyone else has already put in the effort, who am I to say no? ;)

No problem...looks like the main difference was with the struct declarations; since we'll probably hit this more in the future, I'm doing some refactoring that will allow us to share a lot of the PInvoke signatures. I'll add a bigger description in my PR (today or tomorrow, based on how the test run) but I basically added the PInvoke signatures and struct signatures for FreeBSD (based on the headers I found online) and it compiles. I've tested it on Mac so it _should_ (in theory...) work on FreeBSD since it's just a struct declaration change, but your milage may vary :). If it doesn't, you'll have the DriveInfo class and PInvokes 99% of the way there and will just require some tweaking based on FreeBSD nuances.

Excellent news @sokket. I've created you an account on the machine the port-team uses for development, it's european based but it's always on and has heaps of memory and processing power. Hopefully this will help out and remove some of the friction when working w/FreeBSD.

# ssh [email protected]

Password authentication is disabled, use one of your keys.

@josteink see also issue: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo for Mac/FreeBSD)

Are there any updates? Did anybody implement the remaining assemblies on FreeBSD?

I've been busy attending my new baby, haven't had time for any coding anywhere.

I've suspected that issues like these have been lying dormant and I guess this confirms it to a certain extent.

For the assemblies that are still not implemented, I linked the "how to implement"-issue in the list above. I hope that helps coordinating the effort to get these remaining assemblies implemented.

I must admit I was having difficulties keeping track of what we have done and where, so that's definitely a good move. Good job :)

Where do I find that? Would be grat to get the remaining assemblies
implemented.

On 25/07/15 22:10, Jan Henke wrote:

For the assemblies that are still not implemented, I linked the "how
to implement"-issue in the list above. I hope that helps coordinating
the effort to get these remaining assemblies implemented.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-124838781.

This comment here: https://github.com/dotnet/corefx/issues/1626#issuecomment-111800540

I am right now waiting for the native shims to be finished, as these should take over most of the work for getting these assemblies working on FreeBSD.

@nguerrera would be great if you can keep us posted on the progress. :)

Update:
@janhenke confirmed that with https://github.com/dotnet/corefx/pull/2974 merged, System.IO.Pipes builds on FreeBSD! :sunglasses:

Update:
dotnet/corefx#2527 closed, System.IO.MemoryMappedFiles builds on FreeBSD.
Thanks @janhenke for the confirmation!

Thanks to the shims approach, it just comes down to make sure the shims compile on FreeBSD. Thankfully that makes life a lot easier. :)

dotnet/corefx#3257 should bring us both System.Diagnostic.Process and System.IO.FileSystem.Watcher leaving just System.Net.NameResolution unresolved. (I will check the mentioned two assemblies once the PR is merged and works on FreeBSD)

dotnet/corefx#3471 should bring us System.Net.NameResolution and complete the list above.

dotnet/corefx#3471 was just merged :)

@sokket, thanks for the update. I built master (f467911) on FreeBSD using this guide: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. Current blocker is https://github.com/dotnet/buildtools/issues/292, which is fixed in upstream but waiting for next buildtools roll-out. :)

Update: new buildtools with fix for dotnet/buildtools#292 has landed in CoreFX master. Next stopper from buildtools is https://github.com/dotnet/buildtools/issues/300: missing OS specific tool to be able to run the tests.

@janhenke, you have marked System.Diagnostics.Process (#2070) and System.IO.FileSystem.Watcher (#2046) as done; but they are neither implemented nor do they compile on FreeBSD. Have you actually verified the list by compiling the managed code?

Based on my recent experience with commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (see msbuild.log), following assemblies do not compile:

• System.Diagnostics.Process
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(alright, this one was added recently)_

As far as I recall I verified the associated shims compile. Since the managed code should be free of FreeBSD specific code. Those shims you mention should have been shimed out with the PRs linked above.
But I have also run a full compile in between. At the very least System.Diagnostics.ThreadInfoand System.IO.FileSystemWatcher did compile. So something must have regressed.

Those shims you mention should have been shimed out with the PRs linked above.

Actually, PR https://github.com/dotnet/corefx/pull/3257 is not related to shim. There is still some PAL code within the managed projects (the old approach), therefore it is required to build managed assemblies to be absolutely sure.

Actually, PR dotnet/corefx#3257 is not related to shim.

I disagree. It is refactoring the P/Invoke code to the System.Native shim. Also as I edited above, I am recalling at least some of the assemblies compiled in between.

I disagree

https://github.com/dotnet/corefx/pull/3257/files: see the instances of .Unix.cs and .Linux.cs for System.Diagnostics.. Note that .OSX.cs is untouched.

It is refactoring the P/Invoke code to the System.Native shim

Yes it does refactor some common helpers under System.Native, but not System.Diagnostics.* et al.

Even when these assemblies are only P/Invoking to System.* libs, there may still be FreeBSD work required for some of them, e.g. System.Diagnostics.Process and System.IO.FileSystem.Watcher. They are using functionality specific to Linux and OS X, and we don't plan to try to abstract that behind native shims. The goal of the shims isn't to end up with a single managed binary for Unix, though that's a very nice property when it comes from the work; the primary goal is to avoid ABI differences that cause fragility. I expect at least a handful of assemblies will continue to have Linux/OS X specific binaries, where a FreeBSD binary would also be needed.

FYI, there are no corefx assemblies named System.Diagnostics.ProcessManager,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher, or
System.Net.SocketAddress. Those are types in other assemblies.

I expect at least a handful of assemblies will continue to have Linux/OS X specific binaries, where a FreeBSD binary would also be needed.

Does that mean whenever Solaris and non-glibc (musl and μlibc) targeting Linux such as Alpine supports will arrive, they will have separate binaries? And then different architectures ARM, MIPS, RISC, SPARC etc. would require another level of separation?

Wouldn't it make sense to converge them to POSIX interface / sys-calls as much as possible and feature-detect the differences using configs (via CMake) to be used in the same binary (unless it is impacting the size/performance of the assemblies significantly)? As I have understood it, System.Native.so binary has common helper for other specific System.*.Native.so which seems enough for separation-of-concerns principle compliance. But if it gets transformed to System.Net.Http.FreeBSD.ARM.Native.so or System.Net.Http.Solaris.SPARC.so, then it will be quite unmanageable with "too many moving parts" etc.

there are no corefx assemblies named

Good point. I was actually going by the failures instances in msbuild logs and number of .OSX.cs and .Linux.cs files. :smile:

Wouldn't it make sense to converge them to POSIX interface / sys-calls as much as possible

We do. How do you propose doing file watching well via POSIX? How do you propose we do process enumeration well via POSIX?

But if it gets transformed to System.Net.Http.FreeBSD.ARM.Native.so or System.Net.Http.Solaris.SPARC.so, then it will be quite unmanageable with "too many moving parts" etc

I don't understand this. The whole point of the native .so files is that you do get different native binaries for each target platform, but they're not named System.Whatever.Platform.ext, just System.Whatever.ext; that allows the compiler to take the same general logic and use it with the definitions specific to that platform. This only works when the same symbols exist on each platform; the compiler doesn't magically take code written to use inotify and allow it to work with the file watching interface from some other system. In general we've tried hard to use standardized APIs where it makes sense, but for places where such APIs don't exist or aren't well standardized or where there are better platform-specific solutions, we've used the better platform-specific solutions, e.g. using procfs for process enumeration on Linux, using inotify for file system watching on Linux, etc. Whether such platform-specific logic lives in managed or native code doesn't really matter from an ease-of-porting-to-additional-platforms perspective, as when those new platforms come along, if the existing APIs do work, then so does the existing solution, and if it doesn't, then you need to write a new solution for that platform. And so we've tried to do as much as possible in managed code, using native simply for the 1:1 shims that make that managed code much more portable where the target APIs are portable. We've used #ifdefs in the native code to gloss over small details, where this API on what platform is close enough to that API on another platform, but that doesn't extend to entire solutions being completely different; at that point the abstraction becomes the managed API and we do a different managed implementation for each system.

If FreeBSD exposes inotify as Linux does or if it exposes EventStream as OS X does, then when those OS APIs are behind the shim, the shim can easily be made to work with FreeBSD, and the same managed binary can be used on FreeBSD. If FreeBSD doesn't expose such APIs, then you'll need to write a custom implementation of System.IO.FileSystem.Watcher with some file watching solution that is available on FreeBSD. Similar comments for System.Diagnostics.Process. Whether the code for the file watching is in the shim or not has little impact on that.

The plan is for all such native APIs to eventually be moved behind the shim. But they're far from a priority, as they're not very portable, and so you've seen us starting with APIs from libc that are (or are supposed to be) exposed everywhere.

How do you propose doing file watching well via POSIX?

We cannot do all of it POSIX, since inotify is Linux specific. FreeBSD/OSX offers a separate implementations.

Proposal:

From native binaries distribution viewpoint, every OS should receive equal set of binaries with same names, but different functionality.

Here is a proposed structure:

# cmake

check_include_files( "inotify.h" HAVE_INOTIFY_ABILITY )

// config.h.in
cmakedefine01 COREFX_HAVE_INOTIFY_ABILITY
// always a good idea to prefix our headers with project id :)

// header (pal_fsw.hpp) file

#pragma once

class file_system_watcher_shim
{
public:
  void common_function_for_posix_compliants();
  void slightly_diverged_function();
  void painfully_diverged_watch_function();
}

// source (pal_fsw_commons.cpp) file

#include "pal_fsw.hpp"

void file_system_watcher_shim::common_function_for_posix_compliants() {
 // TODO: implement common function for all
}

void file_system_watcher_shim::slightly_varied_function() {

#if COREFX_HAVE_XYZ_ABILITY

  // your way

#else

  // my way

#endif // COREFX_HAVE_XYZ_ABILITY

}

// source (pal_fsw_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement inotify based watcher
}

#endif // COREFX_HAVE_INOTIFY_ABILITY

// source (pal_fsw_non_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if !COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement non-inotify way
}

#endif // !COREFX_HAVE_INOTIFY_ABILITY

This is essentially what we have, e.g.

• "common_function_for_posix_compliants" are natively-shimmed 1:1 functions consumed from logic in a shared Unix managed binary
• "slightly_diverged_function" are natively-shimmed almost 1:1 functions with some native #ifdefs consumed from logic in a shared Unix managed binary
• "painfully_diverged_watch_function" are / will be natively-shimmed 1:1 functions consumed from logic in platform-specific managed binaries

The real difference is whether the code implementing the "painfully diverged" logic is done in C# or C++, and we've chosen C# and it's already all implemented in C#. I've not seen any compelling argument for why in such cases rewriting it all to be in C++ would be a significantly more compelling option.

@jasonwilliams200OK With today's update to mono I build corefx on FreeBSD itself again. There are a lot of new error messages since the last time I build it.
I am wondering if Interop.Libc will go away eventually?

@stephentoub It all comes down to packaging. Having all platform specific code in the native part has the benefit of having one managed assembly for all Unix-like platforms.
Besides, I strongly think we need a generic implementation for these "platform dependent managed code. Even if it just throws a NotImplementedExcpetion. That way you can much easier port to new platforms, if it at least compiles everything right away. Also it would give the chance to at least try running on an unsupported platform.
Generally it is much easier if you can at least compile successfully right away.

@stephentoub, sorry I was mixing C++ with C#. Now i understand that native layer is just exposing those entry points (native libs funcitons or syscalls) and sanitizing IO and managed code is where we decide which platform-specific wrapped utility method / wrapped syscall to be consumed. Besides, both (native and managed) tiers can't be OS-agnostics where non-POSIX functionality is to be consumed.

@janhenke, I agree. I am also building master as we speak. There is another recurring assembly signing issue, I am hitting:

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression.ZipFile/ref/System.IO.Compres
sion.ZipFile.csproj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression.ZipFile/ref/System.IO.Compression.ZipFile.csproj]

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression/ref/System.IO.Compression.csp
roj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression/ref/System.IO.Compression.csproj]

will post the full msbuild.log gist link shortly.

Besides, I strongly think we need a generic implementation for these "platform dependent managed code.

I agree. Instead of partial classes, we can probably use inheritance with common and mostly common virtual methods in abstract base class and override for "mostly common / partly different" where necessary. Then implement abstract methods which are totally different for each OS. With this approach IMO, if where specialization/generalization is losing DRY'ing, we can employee multi-degree inheritance ancestry. But last time I checked, partial classes were preferred over parent-child association in CoreFX (for some reason I don't recall). :)

Here is the msbuild.log for commit 2d36889:

https://gist.githubusercontent.com/jasonwilliams200OK/b375ce52c7b0c90e24af/raw/c895d405a3044dd6acdb26ec49c4b0ced0c76d1a/corefx-msbuild.log

/cc: @akoeplinger

@jasonwilliams200OK Why so complicated. All it needs is a "if not Windows,Linux,OS X" condition in the project files. So either include a platform specific set of files in the build or the generic ones.

I don't think the fact that some assemblies can't build/work for FreeBSD yet should be a major blocker for testing the rest of them. We should probably just make it so that the ones with pending work (FileSystemWatcher, Process, Networking) are skipped in the build and test run on FreeBSD. Then we can bring those up individually while having a process to prevent regression in what already works.

I don't think the fact that some assemblies can't build/work for FreeBSD yet should be a major blocker for testing the rest of them

Agreed

We should probably just make it so that the ones with pending work (FileSystemWatcher, Process, Networking) are skipped in the build and test run on FreeBSD

Or similar to what @janhenke suggested, just allow them to build, either by stubbing out with files that throw PlatformNotSupported, or just by mapping FreeBSD to one of the cases that does work, e.g. if FreeBSD is chosen, just build the Linux one (it won't work, but it'll build).

With @ellismg recent changes (#3684), I am able to run tests by simplifying the previous method (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• After https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (especially the step to build native shims separately _after_ the build.sh exit with status 1), download CoreCLR artifacts zip: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (don't forget the quotes around URL) and then unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx.

(nothing required from Windows machine)

• Ran the test:

./run-test.sh \ --coreclr-bins ../archive/bin/Product/FreeBSD.x64.Debug \ --mscorlib-bins ./packages/Microsoft.DotNet.CoreCLR/1.0.0-prerelease/lib/aspnetcore50 \ --corefx-native-bins ./bin/FreeBSD.x64.Debug/Native

It says:

40 test(s) failed

I don't think the fact that some assemblies can't build/work for FreeBSD yet should be a major blocker for testing the rest of them.

I have to agree with this one. It's better to start QAing the work we have done, instead of waiting on everything to complete before starting testing.

It says: 40 test(s) failed

40 out of how many? In what ballpark are we? :)

40 out of how many? In what ballpark are we? :)

beats me too. The tests are spawning out of test assemblies (managed dlls) and total number of tests is not visible.

The number the script produces at the end is the number of test assemblies that failed. xUnit should write the number of tests that failed per assembly to stdout as part of it's run. The numbers should also be in the XML files it produces in each test assembly folder.

It could be the runtime is also just crashing and in that case there may not be logs produced per test assembly.

@jasonwilliams200OK Do you know if any progress has been made on the assembly signing issue? I'm hitting the same thing on Ubuntu. If no one's working on it, perhaps we should open a separate issue for it.

@naamunds, that has been fixed on CoreFX master as part of https://github.com/dotnet/corefx/issues/3739.

Update - Today I ran tests on FreeBSD, thousands of them were passing and then some were failing due to obvious lack of System.Diagnostics.Process and friends snafu. After ~40 minutes of successful execution, it hung on System.IO.FileSystem tests (for about ~15 minutes before I pressed Ctrl+C to terminate).

@jasonwilliams200OK how did you manage to compile corefx under freebsd? I'm stuck at errors about gssapi

@sec, at the time of making these notes: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24, GSSAPI wasn't required by CoreFX. However, it seems like the pkg is recently ported to FreeBSD: http://www.freshports.org/security/p5-GSSAPI. You may want to try pkg upgrade pkg && pkg update && pkg install p5-GSSAPI.

@jasonwilliams200OK, I already got this (it's perl ext. btw.) Problem was missing gssapi_ext.h. The trick was to do "pkg install krb5" - now native compiled.
I've copied them to coreclr runtime, but still can't run ASP.NET Core app :) fight goes on then.

What's the current status of this task? Is @janhenke's list complete and accurate? Is all work which needs being done, done? Then it should be closed, right?

If so, why do we still have this task? https://github.com/dotnet/corefx/issues/2070

If there's still work to be done, should a new issue be registered based on the current state of affairs?

There's also this needed I think - dotnet/corefx#2046

should a new issue be registered based on the current state of affairs?

Yes :+1:

We discussed community-driven port for FreeBSD with @RussellHaley (from FreeBSD community) and @wfurt (from .NET Core team) who both expressed interest in the work.
Here's a plan proposal we put together (feedback / suggestions are welcome):

1. Produce binaries in CoreCLR & CoreFX repo targeting FreeBSD - using hacks is fine
   
   
   
   • Hard to parallelize, @wfurt will work on that
   
   
   • The build can be mix of builds from other platforms (Mac, Linux) targeting FreeBSD
   
   
   • We will need documented steps (on FreeBSD wiki) to reproduce the build with FreeBSD-specific bug fixes
   
   
2. Run & stabilize CoreCLR tests (using corerun)
   
   
   
   • Tests may be built on another platform
   
   
   • Goal: Provides basic quality of runtime
   
   
3. Run & stabilize CoreFX tests (using corerun)
   
   
   
   • Tests may be built on another platform
   
   
   • Note this requires xunit. We believe, based on our past porting experience, once [2] is done, xunit will just work.
   
   
   • This can be in theory parallelized with [2] - it may require shortcutting xunit (e.g. generate static execution recipe on another platform)
   
   
4. Full stack build on FreeBSD (using corerun as bootstrapper from [1]-[3])
   
   
   
   • We will need all tools (nuget, msbuild, roslyn) to work on boostrapping .NET Core
   
   
5. Installers (FreeBSD ports)
   
   
   
   • First-stage: Using product binaries from nuget feeds
   
   
   • Second-stage: Build product from source (blocked on build from source effort)
   
   
   • Requires FreeBSD community expertise and guidance on design
   
   
   • Note: We can link FreeBSD packages also from official .NET Core download pages as community-support packages
   
   
6. Regular build and test runs on FreeBSD
   
   
   
   • Goal: Make sure changes in .NET Core repos breaking FreeBSD are known early
   
   
   • Design needed
   
   
   • Requires FreeBSD community expertise and guidance on design
   
   

Operation principles:

• Changes in [2]-[4] should be done primarily in CoreCLR/CoreFX repos (due to CLA signing requirements, code reviews from .NET Core team experts/members. etc.)
• We will track high-level work on this issue. Specific bugs will be filed as separate issues.

If anyone is interested in helping, please let us know here. We can easily distribute work items from [2] & [3] above once we are far enough with [1].

The latest version of the proposal is in top-post of this issue.

Tagging more folks who expressed interest on freebsd-mono list (this thread): @smortex @radovanovic @Echo-8-ERA

BTW: I can't find Mathieu Prevot GitHub account -- [UPDATE] Found in https://github.com/dotnet/corefx/issues/1626#issuecomment-330348424: @mprevot

For NetBSD we miss robust posix mutexes, this is the only feature that is still missing to produce named robus mutexes. We can now debug managed code failures with LLDB/NetBSD.. it works fine with core files. In my previous attempts we died on the lack of this feature in LLDB (I started to port this debugger for .NET).

Having better FreeBSD support will significantly help.

There were also problems in the past with lack of hyperv guest support to attach a NetBSD buildbot to CI machines and verify patches... for this I might need help from MS. I expect that there is required proprietary software to run it, which I don't own... I might find a developer to do the job if there would be joint interest (investment) between The NetBSD Foundation and Microsoft.

Where do we miss "robust posix mutexes"? Is it part of .NET Core PAL?

Which CI system are you referring to? Why is it tied to .NET Core port effort?

Where do we miss "robust posix mutexes"?

In the NetBSD kernel (and libc/libpthread), this is a part of CoreCLR. FreeBSD developed it in the last two years. It might be available in the latest stable release.. but there is need to check.

I want to add this feature before my restart of .NET porting. (There was also detected a tiny missing API for network routing.. but I skip it now).

Is it part of .NET Core PAL?

I don't remember now, without checking the code - it's the API used to implement of .NET named robust mutexes (or perhaps semapthores).

Which CI system are you referring to?

NetBSD.

Why is it tied to .NET Core port effort?

It was optional feature last time I looked. I decided to get feature-parity on the kernel-interfaces and utilities (like LLDB). Just my style of work, to get functional buildingblock and later build a house. At some point we will need it anyway so why not to develop it in one go. Thanks for understanding :)

Perhaps you can just tag the freebsd-dotnet group on GH? He is a member there (or you could look up his account name). ‎His email is [email protected]

[EDIT] Delete email heards & previous reply by @karelz

@RussellHaley feel free to tag the larger group if you think it is appropriate. I couldn't find Mathieu's GH account via his name nor email, that's what I meant above (BTW: I pinged him over email directly).

I will look at tagging the group.

Here is Mathieu's account. Perhaps a privacy setting?

https://github.com/mprevot

Cheers,

Russ

On Mon, Sep 18, 2017 at 1:01 PM, Karel Zikmund notifications@github.com
wrote:

@RussellHaley https://github.com/russellhaley feel free to tag the
larger group if you think it is appropriate. I couldn't find Mathieu's GH
account via his name nor email, that's what I meant above.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

I can't see anywhere here mentioned, but what lowest version of FreeBSD we are targeting here (I assume at least 10 and later, but maybe 9 as well)?
(I am also little bit confused what discussion should happen on mono@freebsd mailing list, and what here?)

Well, if Fedora is anything to go by, MS will only support currently supported versions, i.e. 10.3 (10.4 soon) and 11.1.

@radovanovic FreeBSD 9 is not supported anymore, 10 will EoL in april 2018, 11 in 2021. From my expierence there shouldn't be any problems with compiling on 11 vs 10 (and even 9 if you want). FreeBSD is developed with backward compatibility in mind.

@radovanovic I am also little bit confused what discussion should happen on mono@freebsd mailing list, and what here?

I expected the technical discussions, coordination of work and status over here as this is wider audience than mono@freebsd mailing list. OTOH we don't want to have gazillion of random discussions on one issue, so we might take some specific design discussions into separate issues from this one if they grow above reasonable number of replies.

I was finally able to run corefx tests on FreeBSD 11.0 (without outerloop tests)
Total passed: 144208
Total failed: 2622
Total skipped 207

I will update https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD with instructions. I will file specific issues and tag them with with os-freebsd and up-for-grab.
Full scale battle can start. Volunteers needed.

And yes, I did skip proposed step two. I'll get back to it as well.

With some work-in-progress changes the current stats look like:
Total passed: 238892
Total failed: 58
Total skipped 1628

System.Runtime.Tests.dll, 1
System.Net.Ping.Functional.Tests.dll, 7
System.Net.NameResolution.Pal.Tests.dll, 3
System.Net.NameResolution.Functional.Tests.dll, 4
System.IO.MemoryMappedFiles.Tests.dll, 1
System.IO.FileSystem.Tests.dll, 7
System.Globalization.Tests.dll, 2
System.Drawing.Common.Tests.dll, 31
System.Console.Tests.dll, 2

dotnet/corefx#24538 opened to track broken cups support.

Great progress! Adding NetBSD when having FreeBSD support in-tree should be simple.

@wfurt please share E-mail address, I will drop few lines.

The initial support has been merged to master branch. Build should work as described on WIKI page.
I'm slowly progressing on dotnet/corefx#24386 but that should not hold back most users.

Can we already bootstrap .NET on FreeBSD?

I have not tried for a while @krytarowski There was push to update tooling to 2.0 release and I was waiting for that effort to stabilize. I'll give it another try and I'll post update.

Hi, so I'm bogged down with the clr managed tests not running. https://pastebin.com/B5KhtKX5

Any input would be great as that's been an issue for some time. I have also recently run into a build failure on corefx building on Windows(master, Git revision 749194e). https://pastebin.com/JXUySLTY

I assume that's an intermittent problem but it's slowed me down tonight.

If you look at the error:

tests/runtest.sh: line 786: ((: i<: syntax error: operand expected (error token is "<")

And the offending line of code:

bash for (( i=0; i<$maxProcesses; i++ )); do

My gut feeling would be that $maxProcesses is not defined, leading to an incomplete boolean expression:

diff +for (( i=0; i<$maxProcesses; i++ )); do -for (( i=0; i<; i++ )); do

This should be fairly testable. And if that is the case, you just have to go hunting backwards to try to find out how you ended up like this.

Thanks for your help! @josteink :) You're correct. Patch is here: https://pastebin.com/d5y9k1tw

This allows the tests to run, but I gave up at ~1000 errors all of the same nature:

FAILED - JIT/Methodical/casts/iface/_il_dbgiface2/_il_dbgiface2.sh
BEGIN EXECUTION
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize failed - status: 0x80004005
Expected: 100
Actual: 255
END EXECUTION - FAILED

Okay, as per the very excellent information from @janvorli, I was running part of my build in release and part of my build in debug. An embarrassing copy/paste mistake. I'm rebuilding now.

https://github.com/dotnet/coreclr/issues/1419

Patch is here: https://pastebin.com/d5y9k1tw

If you have a patch which fixes a broken build, I would recommend sending it as a pull-request so that it gets fixed for everyone :)

Thank you, I will. I'm still working on getting tests to run though and I wasn't sure what was causing the subsequent error last night.

I suppose Freebsd 11 "pkg install" support for netcore 2.1 (once released) won't happen, right?

TLDR; Lots of work has been done, but there needs to be someone to drive it home. Writing the port Makefile is the easy part.

@wfurt was able to get the CLR and the FX to build using Linux but it was largely untested. I was able to get the 'native' parts to build on FreeBSD but stalled out getting the managed parts to build on Windows (for FreeBSD). The whole thing was a mess of transferring files between operating systems.

Separately on the [email protected] mailing list, @dragonsa has imported a binary version of Dot Net Core 1 and all the toolschain (msbuild, nuget etc) from MintOS using Linux emulation. I've been able to use his patches and run some of the tools but never got around to building anything. I'm not sure if these patches have been committed yet; I was in the middle of reviewing them and I changed jobs. I don't have any DotNet in my current role and am ramping on other things right now.

What does all that mean? If someone can verify @dragonsa's patches he can push them the ports tree, then it's technically possible to build core 2 on FreeBSD natively. As you can see, though, there are lots of little parts that need to be brought together and organized. I've dropped the ball on that so someone needs to pick it up. I suggest jumping on the [email protected] mailing list. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Thanks for the writeup Russell.

Hi,

Discussing this with a .NET dev here, I'm willing to assist with the development of a FreeBSD port/package.

Full disclosure: I'm not a .NET developer however I'm willing to work with whomever to get this into the tree.

~cy

@cschuber I've been too busy to keep an eye on the current status of things, but as someone who submitted a lot of FreeBSD-patches and managed to get Hello World running around 3 years ago, it would be awesome if we could finally see this thing getting properly landed. You have my full support :)

@cschuber, the current active issues is https://github.com/dotnet/coreclr/issues/18067. Mainly these four features are left https://github.com/dotnet/corefx/issues?q=is:open+label:os-freebsd+label:up-for-grabs+is:issue, among which Filesystem watcher seems to be the most tricky/laborious one https://github.com/dotnet/corefx/issues/2046.

Thanks for the offer @cschuber. We are almost at point when it may be possible.
We've been working recently with @mateusrodrigues on getting .net working on FreeBSD and he is trying to get PowerShell working. List @kasper3 sent are are primarily missing features. I think we can throw PNSP for now. From my prospective most pressing issues are dotnet/corefx#30698 and https://github.com/dotnet/coreclr/issues/18481. It would be great if anybody from the community can dig into them. I did not run tests recently, but I fear the number of failures went up.
We should open issue for each new failing group.

I also start fixing source-build but there are still some challenges ahead.
c# compiler is written in c#. Current .net build uses previous version of .net to produce managed assemblies. It also depends on packages from Nuget.
Right now, we have good enough bootstrap cli that we can be build coreclr, corefx and few other repos on FreeBSD. I did not update building instructions yet to reflect 2.1 changes and source-build.

+1 Just a note to say I'm glad this still has some momentum. It's hard to follow with so many moving parts but seems like people are making progress. I created https://github.com/dotnet/coreclr/issues/6115 a while ago but the project I was working on then got put on hold. I really hope it's as easy as pkg install dotnet && dotnet build one day (without linux compat).

Also looking forward for this

We got daily builds going now. One can get runtime or sdk here: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz and
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

It is also possible to cross-target e.g. on Linux or Windows one can do dotnet publish -r freebsd-x64 and that would create self-contained FreeBSD application.

It is still incomplete and unsupported but it should make it easier for anybody to contribute.
It would be great if people can give it try, report issues.
Also this would be good time for final push to close feature gap and fix bugs.

cc: @mateusrodrigues

Nice job, @wfurt and @bartonjs.

When I proposed my first FreeBSD commits around 2-3 years ago, I didn’t actually believe we’d get here, but I certainly wanted to try.

This is definitely a big milestone and hopefully will make it easier for new contributors help finish the port.

Big thanks to everyone who helped us get this far 👍

Great progress! I'm still fighting with toolchain (most LLVM projects besides LLDB and LLD are finished) and hardware assisted virtualization for NetBSD (Linux/BSD now starts booting until a VTx fatal exception, simpler OSes like FreeDOS already work).. so I will resume my NetBSD porting, hopefully sooner than later. Better FreeBSD support will help with an easier resume.

Awesome :)

We celwbrate drunkness why the ensil bombsrdment??

@krytarowski Can you develop in which ways 'FreeBSD support' can be better ?

It would be great if some FreeBSD guru could take look at https://github.com/dotnet/coreclr/issues/22124 I would expect binaries build for 11 to run on 12 but it does not seems to be the case ;(
It is easy to reproduce with simple app and 12.0 release seems to break something dotnet depends on.

Hi, I'm no guru but we ran across a threading regression in 12-RELEASE in the Lua53 port.
See here for the original bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
and here for the Base system bug that was identified: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (note the base system bug identifies code that can be used to reproduce the issue for comparison).

The fix for Lua is to link against -pthread, even though there is ZERO requirement from Lua for -pthread.

thanks @RussellHaley. That looks like promising lead.

Glad I could help. I'd love to be playing along but I barely have the few hours needed to maintain the Lua port. Keep up the great work!

As the one who fixed the FreeBSD threading implementation in coreclr, I think pthreads are used pretty consistently all over, because that was what I had to patch up to make the build run.

That said, there might be underlying buts and pieces that I never had to touch which uses "regular" threads...

Maybe someone else who knows more about the general implementation can chime in? @janvorli ?

This fixes the issue for me:

[furt@daemon ~]$ LD_PRELOAD=/usr/lib/libpthread.so ./dotnet-3.x/dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010021
 Commit:    d5c97b7c2a

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/furt/dotnet-3.x/sdk/3.0.100-preview-010021/

Host (useful for support):
  Version: 3.0.0-preview-27218-01
  Commit:  d40b87f29d

.NET Core SDKs installed:
  3.0.100-preview-010021 [/usr/home/furt/dotnet-3.x/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 3.0.0-preview-27218-01 [/usr/home/furt/dotnet-3.x/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I did not make any extensive tests but at least I can execute dotnet again.

Ok, I can see that the dotnet executable is not linked with pthreads for other systems than Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59-L61

Does that mean the answer to fixing this is as simple as it sounds? I.e. as simple as this? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

If so, I'll be happy to make it a PR.

Yes I think so. I was waiting for @joperator to confirm.
Not sure if we need "dl" as well but that can be resolved when you submit PR @josteink

Right. My bad. So more like this then: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

I've created a PR for it. Let me know if it needs any ammending: https://github.com/dotnet/core-setup/pull/5072

Right. My bad. So more like this then: josteink/core-setup@a08f38e

I've created a PR for it. Let me know if it needs any ammending: dotnet/core-setup#5072

Just an FYI, it seems this is already patched in the base system: https://reviews.freebsd.org/D18988

Looks like the main issue in dotnet/coreclr#22124 is fixed @wfurt.
I only have a problem when trying to publish a self-contained app on FreeBSD 12.0.

freebsd-x64 official NuGet packages has been removed since .NET Core 3.0 preview 2 and we were unable to publish apps for FreeBSD since then. Are there any plans to re-enable them in 3.0?

Sadly, we had to de-prioritize FreeBSD bring up (due to various reasons and difficulties in the end-to-end Azure support) and it is not going to be priority in .NET Core 3.0.
We would love to keep it semi-working at the state where it is now, but we do not have much time to invest now :(.

@karelz Thanks for your reply and I understand the prioritized work of .NET Core 3.0. I'll focus on bringing up my apps with FreeBSD Linux emulation then. :)

@hjc4869 Or you can try mono. IIRC, it will support .NET Standard 3.0

I'm planning to give it another try but as @karelz mentioned it is not priority for 3.0

@newsash Mono is an acceptable option for me. However I found it difficult to build my project with the mono targets added to existing .NET Core csproj files.

On a Linux machine I tried adding net472 to TargetFrameworks and setting the FrameworkPathOverride variable but that did not work well. If I consume an API that is implemented in both mono and .NET Core, but not .NET Framework, it will fail to build with mono. Besides, although mono supports .NET Standard 2.1, I still couldn't add reference to .NET Standard 2.1 dlls in an net472 csproj.

Should I add a separate csproj and use mono msbuild instead of using dotnet tools, or do you have any suggestions on the problem?

Just a quick remark.

With mono about to be swallowed by .NET 5 as per the recent announcement [1], providing decent support for FreeBSD has become urgent.

Mono has proven to have really good cross-platform support and can be built without problem from FreeBSD ports. Many shops run their .net loads on FreeBSD since this OS has many unique features. So far, mono has been bridging the gap but with .NET 5 it seems likely that in some near future, mono will be merged into NET 5 and the FreeBSD community will be totally cut-off from the .NET ecosystem.

Dotnet should have mature FreeBSD support well before this happens.

I think Microsoft should officially support FreeBSD at this point and ensure all the dotnet tooling builds on this platform.

@jasonpugsley put together instructions https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD and @joperator is trying to get source-build working https://github.com/dotnet/source-build/issues/1139

We have last ~30 tests failing for corefx.

System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet64
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize
System.Diagnostics.Tests.ProcessTests.Kill_ExitedNonChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.TotalProcessorTime_PerformLoop_TotalProcessorTimeValid
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_EntireTreeTerminated
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize
System.Diagnostics.Tests.ProcessTests.ProcessNameMatchesScriptName
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize64
System.Diagnostics.Tests.ProcessTests.LongProcessNamesAreSupported
System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize64
System.Diagnostics.Tests.ProcessTests.Kill_ExitedChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_CalledOnTreeContainingCallingProcess_ThrowsInvalidOperationException
System.IO.Tests.DirectoryInfo_MoveTo.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.IO.Tests.FileInfo_Exists.LockedFileExists
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 0, firstLength: 10, secondPosition: 1, secondLength: 2)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 6)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 6)
System.IO.Tests.Directory_Move.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntryAsync_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteGetHostByName_EmptyString_ReturnsHostName
System.Net.NetworkInformation.Tests.PingTest.SendPingAsyncWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.NetworkInformation.Tests.PingTest.SendPingWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.Sockets.Tests.DualModeAcceptAsync.AcceptAsyncV4BoundToSpecificV4_Success
System.Tests.AppDomainTests.MonitoringIsEnabled
System.Tests.GCExtendedTests.GetGCMemoryInfo

@am11 is looking at System.Diagnostics.Tests.ProcessTests so failing locking tests seems biggest remaining gap. It would be great if anybody can take look dotnet/corefx#30899.

Just wondering if there are any updates on this or if it's abandoned?

@elfalem, these days FreeBSD CI leg (that cross-compiles from Ubuntu) is running on dotnet/runtime PRs. It uses a docker image from https://github.com/dotnet/dotnet-buildtools-prereqs-docker/, that has all the prereqs installed. We can use the same docker container to publish runtime package (basically a tar.gz), locally or a remote machine. e.g. we can set up a GitHub Action in one of our fork branch, something like: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml, that uploads artifacts to GitHub releases on tag push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. The dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz archive in this case has enough bits to just run a published dotnet application (from a different linux/mac system, that has dotnet SDK). I tested it by creating a new 12.2 VM (vagrant), extracted and copied a published app from mac to VM, it worked:

#!/usr/bin/env tcsh

$ sudo pkg install libunwind icu libinotify

$ fetch https://github.com/am11/runtime/releases/download/6.0.0-dev.freebsd.1/dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz
$ mkdir ~/.dotnet
$ tar xzf dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz -C ~/.dotnet

$ set PATH=(~/.dotnet:$PATH)
$ setenv PATH "$PATH"

$ dotnet /vagrant/MyPublishedApp.dll
Hello World!

I think @Thefrank was looking into creating a proper FreeBSD Ports package at some point.

Just wondering if there are any updates on this or if it's abandoned?

you might want to look at https://github.com/dotnet/source-build/issues/1139
I have not tried recently as I wait for dotNET5 final but, as of a few months ago, FreeBSD runtime could only be built as a cross compile on Linux. ASPNet and SDK also required Linux cross compile but only built if the stars aligned (arcade updates or some other automated bot didn't break a dependency)

edit: and @am11 posted a better write up while I was typing up a late-night ramble. read that and not mine
edit2: forgot punctuation and it looks like final was put out 2 days ago. guess I should get working on that or something

Aside from all the above, I created FreeBSD project in https://github.com/dotnet/runtimelab/ and I'm slowly progressing on getting packages built and published. The goal is to build and publish enough for app to run on FreeBSD and have seed for source-build.

I thought I'd write a quick update. I finally got all of the planets aligned to build 5.0.0 RTM on FreeBSD. I hadn't kept up since Preview3 and it took a while (and _many_ build attempts) to find the right combination of compatible builds to get a successful 5.0.
I've been able to build PowerShell 7.1.0 with surprisingly few hacks, it works though I haven't tested it thoroughly but it seems like a good test of the SDK.
I've only just built AspNetCore but I haven't tested it at all yet.

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  11
 OS Platform: FreeBSD
 RID:         freebsd.11-x64
 Base Path:   /tmp/rtm/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  5.0.100 [/tmp/rtm/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /tmp/test/test.csproj...
  Determining projects to restore...
  Restored /tmp/test/test.csproj (in 106 ms).
Restore succeeded.

$ dotnet run
Hello World!
$

$ LANG=en-US ./pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp/powershell> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             FreeBSD 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020     [email protected]:/usr/obj/usr/src/sys/GE…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /tmp/powershell> Get-Host

Name             : ConsoleHost
Version          : 7.1.0
InstanceId       : fa711f95-926c-47e4-9e0c-dff0f518f825
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace


PS /tmp/powershell>

The only issue with doing this work manually (i.e. outside of the CI system) is the trouble caused by breaking changes requiring a particular build to be available for the next build to use. It doesn't happen often but it requires a lot of trial and error to find the correct commit. Having the linux cross-build in the CI system should fix that but I haven't looked at that yet. Still it's good to know I can build a complete SDK and then use that SDK to build something else.

russellh@freebird:/www/winlua_net/htdocs/downloads$ pkg search dotnet
linux-dotnet-cli-2.0.7         Cross-platform .NET implementation
linux-dotnet-runtime-2.0.7     Cross-platform .NET implementation
linux-dotnet-sdk-2.1.201       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet10-runtime-1.0.11  Cross-platform .NET implementation
linux-dotnet10-sdk-1.1.9       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet11-runtime-1.1.8   Cross-platform .NET implementation

That is good progress @jasonpugsley. I'm trying to find better answer for the build but I was unable to put in any decent chunk of time in last few month ;(
Did PowerShell give you any grief because of terminfo or did you copy terminal definition from elsewhere?

I grabbed the terminal definition from my Mac where I was ssh'd from.

@jasonpugsley you are way ahead of me. core and sdk build from linux cross freebsd. run fine from the limited testing ive done. neither runtime nor sdk crossbuilts are able to build on freebsd themselves (linux and freebsd are using llvm9 and clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
ill poke at it a bit more if I have more time this weekend and also see if I can atleast get aspnetcore built on linux for freebsd

@Thefrank, do you mean:

$ ROOTFS_ENV="ROOTFS_DIR=/crossrootfs/x64"
$ DOTNET_DOCKER_TAG="mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-freebsd-11-20201109180854-f13d79e"
$ docker run -e $ROOTFS_ENV -v $(pwd):/runtime $DOTNET_DOCKER_TAG /runtime/build.sh -c Release -cross -os freebsd

is failing or the binaries in artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz failed to execute?
If you are trying to crosscompile SDK 5x on Ubuntu 18 or 20, you might want to apply this patch https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (it's on master branch).

I really need to stop making posts when half asleep.
Building of the runtime and sdk completes on linux.
Those binaries run on freebsd (dotnet --info, new console, and run)
Those binaries are unable to create a runtime or sdk from source on freebsd

Ah ok. I haven't tried dogfodding the stage0 binaries to rebuild the runtime on FreeBSD as HostOS.

ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

Might be worth reporting this issue separately. Likely there are multiple ways of fixing it, but does this patch make any difference:

--- a/eng/native/functions.cmake
+++ b/eng/native/functions.cmake
@@ -211,7 +211,7 @@ function(generate_exports_file)
   list(GET INPUT_LIST -1 outputFilename)
   list(REMOVE_AT INPUT_LIST -1)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)
@@ -229,7 +229,7 @@ endfunction()

 function(generate_exports_file_prefix inputFilename outputFilename prefix)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)

does this patch make any difference

I would expect FreeBSD to follow Linux as far as symbol version scripts go, not Darwin. IMO it's more likely that the issue is that there's something GNU-awk specific in generateversionscript.awk

patch changed the error:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
if awk version issue:

awk --version
awk version 20121220 (FreeBSD)

If it is easy to experiment, can you try installing the gawk package and change the invocation in the CMake files to gawk?

reverted the patch. installed gawk pkg.
too lazy to figure out how the build.sh script passes cmake args as it doesnt immediately make sense so I just symlinked gawk->awk.
same original error
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

late edit: it looks like the binaries on linux did not build correctly:

# ./dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101-servicing.20605.0
 Commit:    c3a779b104

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         osx-x64
 Base Path:   /root/runtime/.dotnet/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.1
  Commit:  2ee13ec8e5

.NET SDKs installed:
  5.0.100 [/root/runtime/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 5.0.1 [/root/runtime/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

mainly the RID: osx-x64 might be causing some issues

mainly the RID: osx-x64 might be causing some issues

That RID is displayed by the SDK after some resolutions of supported vs. non-supported platforms. It basically has no effect on execution of application. The real RID detected by the runtime is correct, otherwise applications (such as dotnet(1)) will not execute properly.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
prints Real RID: freebsd.12-x64 on my box.

Opened #45663 for tracking the ld issue. I was able to reproduce as well.

@Thefrank regarding the ld error, try this:

diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake
index 006a180fa0a..2a270572532 100644
--- a/eng/native/configurecompiler.cmake
+++ b/eng/native/configurecompiler.cmake
@@ -594,7 +594,7 @@ else (CLR_CMAKE_HOST_WIN32)
         ERROR_QUIET
         OUTPUT_VARIABLE ldVersionOutput)

-    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold")
+    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold" OR "${ldVersionOutput}" MATCHES "LLD")
         set(LD_GNU 1)
     elseif("${ldVersionOutput}" MATCHES "Solaris Link")
         set(LD_SOLARIS 1)

That will activate the else clause in eng/native/functions.cmake here:

function(set_exports_linker_option exports_filename)
    if(LD_GNU OR LD_SOLARIS)
        # Add linker exports file option
        if(LD_SOLARIS)
            set(EXPORTS_LINKER_OPTION -Wl,-M,${exports_filename} PARENT_SCOPE)
        else()
            set(EXPORTS_LINKER_OPTION -Wl,--version-script=${exports_filename} PARENT_SCOPE)
        endif()
    elseif(LD_OSX)
        # Add linker exports file option
        set(EXPORTS_LINKER_OPTION -Wl,-exported_symbols_list,${exports_filename} PARENT_SCOPE)
    endif()
endfunction()

To be quite honest, I'm no linker expert so while this works, I didn't look deeper to see what was actually required/canonical for clang on FreeBSD.

Ahh, the linker user-agent issue strikes again. LLD's version string includes (compatible with GNU linkers) in an attempt to go down the GNU ld path of configure tests but clearly not clever enough for this case :)

Matching on LLD looks good here even if the LD_GNU flag is now somewhat misnamed.

Yes it needs more work. The flag name is now confusing. Please don’t anyone try to commit this as-is.

From: Ed Maste notifications@github.com
Sent: Monday, December 7, 2020 10:26:48 AM
To: dotnet/runtime runtime@noreply.github.com
Cc: Jason Pugsley jason.pugsley@gmail.com; Mention mention@noreply.github.com
Subject: Re: [dotnet/runtime] Support for FreeBSD (#14537)

Ahh, the linker user-agent issue strikes again. LLD's version string includes (compatible with GNU linkers) in an attempt to go down the GNU ld path of configure tests but clearly not clever enough for this case :)

Matching on LLD looks good here even if the LD_GNU flag is now somewhat misnamed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/runtime/issues/14537#issuecomment-739583816, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPA.

I opted to use https://github.com/dotnet/runtime/pull/45664
Clr builds up to Clr.Tools subset then fails with

/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libjitinterface" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]
/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libclrjit" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]

subset "mono" and subset "libs" complete with no errors

@Thefrank It's the second part of this diff you need to fix that issue:

diff --git a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
index 2de5f568214..87242a728f0 100644
--- a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
+++ b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
@@ -12,7 +12,7 @@
     <OutputPath>$(BinDir)/crossgen2</OutputPath>
     <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
     <EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
-    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64</RuntimeIdentifiers>
+    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64;freebsd-x64</RuntimeIdentifiers>
     <Configurations>Debug;Release;Checked</Configurations>
   </PropertyGroup>

@@ -53,6 +53,7 @@
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('WINDOWS'))">.dll</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('LINUX'))">.so</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('OSX'))">.dylib</LibraryNameExtension>
+    <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('FREEBSD'))">.so</LibraryNameExtension>

     <JitInterfaceLibraryName>$(LibraryNamePrefix)jitinterface$(LibraryNameExtension)</JitInterfaceLibraryName>
   </PropertyGroup>

It might be better added to the LINUX line as an OR in the condition.

@jasonpugsley that did the trick!
/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s):
I knew I forgot to do something a few days ago! This should be interesting

edit: without crossgen (aka just second half)

./build.sh -c Release -bl:buildlog.binlog

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:12:05.56

edit last edit on this post I swear:
I know tests can take a while and it does say long running test but this getting out of hand for one test
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

killed the test after waiting 2hr other tests still had failures

/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.Extensions.Hosting.Unit.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.Extensions.Hosting.Unit.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/Microsoft.Extensions.Hosting.Unit.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NameResolution.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NameResolution.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NetworkInformation.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NetworkInformation.Functional.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NetworkInformation/tests/FunctionalTests/System.Net.NetworkInformation.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.VisualBasic.Core.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.VisualBasic.Core.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.VisualBasic.Core/tests/Microsoft.VisualBasic.Core.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Console.Tests'. Please check /root/runtime/artifacts/bin/System.Console.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Console/tests/System.Console.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Extensions.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Extensions.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime.Extensions/tests/System.Runtime.Extensions.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Sockets.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Sockets.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/System.Net.Sockets.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.IO.FileSystem.Tests'. Please check /root/runtime/artifacts/bin/System.IO.FileSystem.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Ping.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Ping.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Ping/tests/FunctionalTests/System.Net.Ping.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Requests.Tests'. [/root/runtime/src/libraries/System.Net.Requests/tests/System.Net.Requests.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebSockets.Client.Tests'. [/root/runtime/src/libraries/System.Net.WebSockets.Client/tests/System.Net.WebSockets.Client.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.X509Certificates.Tests'. Please check /root/runtime/artifacts/bin/System.Security.Cryptography.X509Certificates.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Security.Cryptography.X509Certificates/tests/System.Security.Cryptography.X509Certificates.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebClient.Tests'. [/root/runtime/src/libraries/System.Net.WebClient/tests/System.Net.WebClient.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Security.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Security.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Security/tests/FunctionalTests/System.Net.Security.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Diagnostics.Process.Tests'. Please check /root/runtime/artifacts/bin/System.Diagnostics.Process.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.Xml.Tests'. [/root/runtime/src/libraries/System.Security.Cryptography.Xml/tests/System.Security.Cryptography.Xml.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.HttpListener.Tests'. [/root/runtime/src/libraries/System.Net.HttpListener/tests/System.Net.HttpListener.Tests.csproj]
    0 Warning(s)
    18 Error(s)

Time Elapsed 02:11:29.07
Build failed (exit code '1').