Support for FreeBSD

[ghuntley]

Updated proposal from 2017/9

Proposal (by @karelz - #1626 (comment)) 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 #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)

• #1625 (OSGroup identifier in the public API)
• #1576 (OSGroup identifier in the private API)

/cc: @janhenke @josteink

[josteink]

There seems to be agreement as far as #1576 is concerned.

When we also have a decision on #1625 we should be able to start shipping some code.

[josteink]

There seems to be agreement as far as #1576 is concerned.

When we also have a decision on #1625 we should be able to start shipping some code.

[ghuntley]

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

[ghuntley]

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

[josteink]

Agreement on #1625 has been reached by the portteam, unless MSFT chooses otherwise it will be FreeBSD

If I read that right, this means that when #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.

[josteink]

Agreement on #1625 has been reached by the portteam, unless MSFT chooses otherwise it will be FreeBSD

If I read that right, this means that when #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.

[ghuntley]

Next steps as per #1999 (comment) are:

1. The "FreeBSD port team" continues their work to get a FreeBSD version of CoreFX produced (tracked by #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 #1625, which adds the property.

[ghuntley]

Next steps as per #1999 (comment) are:

1. The "FreeBSD port team" continues their work to get a FreeBSD version of CoreFX produced (tracked by #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 #1625, which adds the property.

[josteink]

That sounds like a fully reasonable plan to me.

[josteink]

That sounds like a fully reasonable plan to me.

[janhenke]

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

[janhenke]

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

[josteink]

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.

[josteink]

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.

[stephentoub]

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.

[stephentoub]

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.

[josteink]

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]

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.

[akoeplinger]

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

[akoeplinger]

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

[josteink]

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

[josteink]

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

[ajensenwaud]

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 notifications@github.com 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.

[ajensenwaud]

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 notifications@github.com 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.

[stephentoub]

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. 😉 If both can be worked on in parallel, all the better.

[stephentoub]

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. 😉 If both can be worked on in parallel, all the better.

[ghost]

@ghuntley,
would be super 🆒 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! 😎

[ghost]

@ghuntley,
would be super 🆒 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! 😎

[janhenke]

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

• Introduce FreeBSD platform to the build tools and scripts. (Done by @josteink and me, PRs #2021 merged, #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):

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

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

[janhenke]

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

• Introduce FreeBSD platform to the build tools and scripts. (Done by @josteink and me, PRs #2021 merged, #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):

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

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

[josteink]

FYI: PR #2039 merged

[josteink]

FYI: PR #2039 merged

[josteink]

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?

[josteink]

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?

[janhenke]

I suggest we stub that out for the moment and throw a PlatformNotSupportedException as Stephen Toub suggested in the other topic (#2021 (comment)). 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?

[janhenke]

I suggest we stub that out for the moment and throw a PlatformNotSupportedException as Stephen Toub suggested in the other topic (#2021 (comment)). 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?

[ghuntley]

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

[ghuntley]

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

[ghost]

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

[ghost]

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

[ghuntley]

@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 - dotnet/buildtools#180
• Reapply [Fact,PlatformSpecific(PlatformID.FreeBSD)] tests to CheckPlatformTests - see #2068 (comment) and #2068 (comment)
• Add public static OSPlatform FreeBSD to #2068

[ghuntley]

@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 - dotnet/buildtools#180
• Reapply [Fact,PlatformSpecific(PlatformID.FreeBSD)] tests to CheckPlatformTests - see #2068 (comment) and #2068 (comment)
• Add public static OSPlatform FreeBSD to #2068

[ghuntley]

@jasonwilliams200OK there were some discussions last night about System.Diagnostics.Process in gitter which have been formalized into #2070

[ghuntley]

@jasonwilliams200OK there were some discussions last night about System.Diagnostics.Process in gitter which have been formalized into #2070

[ghost]

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

[ghost]

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

[josteink]

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]

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?

[ghost]

@josteink, great diggings! Based on #815 (comment) and #1729, I think we should collaborate with @sokket to come up with a solution with works across different Unices.

[ghost]

@josteink, great diggings! Based on #815 (comment) and #1729, I think we should collaborate with @sokket to come up with a solution with works across different Unices.

[sokket]

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

[sokket]

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

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

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

[sokket]

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.

[sokket]

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.

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

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

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

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

[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]

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

#24538 opened to track broken cups support.

[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

#24538 opened to track broken cups support.

[krytarowski]

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

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

[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 #24386 but that should not hold back most users.

[wfurt]

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

[krytarowski]

Can we already bootstrap .NET on FreeBSD?

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

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

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

[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]

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.

dotnet/coreclr#1419

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

dotnet/coreclr#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 :)

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

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

[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

[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

[oliverw]

@russellhadley Thanks for the writeup Russell.

[oliverw]

@russellhadley Thanks for the writeup Russell.

[cschuber]

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]

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

[josteink]

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

[josteink]

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

[ghost]

@cschuber, the current active issues is dotnet/coreclr#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 #2046.

[ghost]

@cschuber, the current active issues is dotnet/coreclr#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 #2046.

[wfurt]

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 #30698 and dotnet/coreclr#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.

[wfurt]

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 #30698 and dotnet/coreclr#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.

[josh-endries]

+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 dotnet/coreclr#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).

[josh-endries]

+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 dotnet/coreclr#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).

[bott0r]

Also looking forward for this

[bott0r]

Also looking forward for this