Support for FreeBSD

[ghuntley]

Updated proposal from 2017/9

Proposal (by @karelz - https://github.com/dotnet/corefx/issues/1626#issuecomment-329840518) will be updated in top-post based on further discussion and proposal changes.

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)
   • We can expose new OSPlatform API for FreeBSD when the pass rate is reasonable: see dotnet/corefx#23989
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].

---

Original proposal from @ghuntley from 2015/5

This issue is to discuss unit(s) of work to actually produce FreeBSD assemblies for corefx.

@stephentoub - There's what's likely a more pressing issue, which is actually building for FreeBSD. Today, when we need to specialize an assembly for a particular platform, we effectively have three builds, producing three different managed assemblies: Windows, Linux, OSX. Sounds like at least for now we'll need a fourth, FreeBSD. I suggest you start by modifying the build to support an IsFreeBSD property (or just IsBSD of you think there's a high chance that the implementations across BSDs will be the same even with varied kernels) along with the appropriate OSGroup targets. That can then be used in the csproj files as needed to specialize an assembly with FreeBSD-specific code.

Related issue(s)

• dotnet/runtime#14536 (OSGroup identifier in the public API)
• dotnet/runtime#14507 (OSGroup identifier in the private API)

/cc: @janhenke @josteink

[ghost]

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:

[stephentoub]

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.

[ghost]

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

[stephentoub]

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.

[janhenke]

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

[ghost]

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

[ghost]

Here is the msbuild.log for commit 2d36889:

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

/cc: @akoeplinger

[janhenke]

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

[nguerrera]

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.

[stephentoub]

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

[ghost]

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

[josteink]

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? :)

[ghost]

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.

[ellismg]

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.

[naamunds]

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

[ghost]

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

[ghost]

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

[sec]

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

[ghost]

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

[sec]

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

[josteink]

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?

[sec]

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

[ghost]

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

Yes :+1:

[karelz]

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.

[karelz]

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

[krytarowski]

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.

[karelz]

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?

[krytarowski]

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

[RussellHaley]

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 mprevot@freebsd.org

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

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

[RussellHaley]

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 .

[radovanovic]

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

[Echo-8-ERA]

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.

[sec]

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

[karelz]

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

[wfurt]

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.

[wfurt]

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.

[krytarowski]

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

[krytarowski]

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

[wfurt]

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.

[krytarowski]

Can we already bootstrap .NET on FreeBSD?

[wfurt]

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.

[RussellHaley]

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.

[josteink]

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:

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

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

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

[RussellHaley]

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

[RussellHaley]

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

[josteink]

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

[RussellHaley]

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.

[oliverw]

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

[RussellHaley]

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 freebsd-mono@freebsd.org 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 freebsd-mono@freebsd.org mailing list. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html