Support for FreeBSD #14537
Comments
|
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 #14536 has been reached by the portteam, unless MSFT chooses otherwise it will be |
If I read that right, this means that when dotnet/corefx#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 dotnet/corefx#1999 (comment) are:
|
|
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: |
FWIW, I personally don't think this is the first obstacle. There are two build related issues:
(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. |
…tion. This partially adresses https://github.com/dotnet/corefx/issues/1626
This partially adresses https://github.com/dotnet/corefx/issues/1626
|
@josteink btw. corefx should now build on Mono 4.0.1.44. |
This partially adresses https://github.com/dotnet/corefx/issues/1626
This partially adresses https://github.com/dotnet/corefx/issues/1626
|
@akoeplinger Nice. That leaves me some hope we can get it running on FreeBSD too :) |
This partially adresses https://github.com/dotnet/corefx/issues/1626
|
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.
|
|
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. |
|
@ghuntley, renders as:
This will probably encourage others to score those feats and FreeBSD support will land rather sooner than anticipated! 😎 |
|
To my knowledge the following pieces of work in CoreFX are required for FreeBSD support:
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):
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 Iirc FreeBSD has no |
|
I suggest we stub that out for the moment and throw a PlatformNotSupportedException as Stephen Toub suggested in the other topic (dotnet/corefx#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? |
|
Let's move |
|
Guys is there any such blocker for |
|
@jasonwilliams200OK added FreeBSD to S.RT.I.RI early this morning which was merged but the FreeBSD tests within
|
|
@jasonwilliams200OK there were some discussions last night about |
|
@ghuntley, thanks. I actually read those messages. |
As discussed in the gitter, For this one I tried looking into basic usage of #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: 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 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: 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. |
|
Hello from the FreeBSD Foundation. I wanted to drop a quick note in here to express my immense gratitude to the engineers who have made this happen. As folks here know, support for .NET in FreeBSD, while of course key to running .Net apps, has a cascading impact on the ability for the FreeBSD community to merge patches into open source projects that use GitHub Actions and for enterprises and vendors with FreeBSD-based systems to efficiently use Azure Pipelines. Looking to next steps, I’m very interested in people’s thoughts on:
Thank you again! Greg |
|
@gtewallace I am not an enterprise or enterprise user so this feedback might not be as useful. Warning for readers: This will be on the verbose side.
Let me break this question down a bit Building!Breakages From personal experience direct build breakage comes either from this repo or from missing NuGets from the Installer repo when generating portable builds. These are both rare. Runtime: Installer: The VMR The FreeBSD port uses the VMR. This is the suggested way of building net8 or higher from source. FreeBSD can not use the VMR nor source-build repo for earlier versions (e.g. net6 and net7) which are still in support so the options here are either crossbuilding or native building SDKs from repo tags. Most (all?) patches that are needed to build the VMR are either already merged or in PRs. This won't help net8 versions of the VMR/port but it will mean future versions require fewer if any patches. Testing!Microsoft has an extensive system for testing. FreeBSD is not a part of that system. For a while I did nightly a build+test of the runtime but gave up as keeping up with minor version changes of the components needed became too much. Running a complete set of tests took more than 1hr on my (rather old) setup. The VMR has smoke tests but those are Linux/OSX based. It should be rather easy to add cases/exceptions for FreeBSD but getting that to work in the port system might be challenging. Help with regular testing would be great but I don't even know where to begin with this.
This question might be better suited for large-scale users of those products but here is my side GH Actions/runners:Actions: Runners: The work-around for this is a VM-in-VM solution. This is less than ideal but still an alternative. AZP:This actually works!...after patching...and unwise patching. I have used this on FreeBSD 12.x and also works on 13.2 and 14.0 Other tools/tooling?Things that you can Support in the port system would be nice too but the number of ports that use dotNET, I can count on one hand. For now, I am skeptical of dedicating resources to get this setup. Finally, most of this wider adoption depends on FreeBSD becoming an officially supported platform for dotNET. |
Engaging with Microsoft at a corporate level (product managers, etc...) to make the case that supporting FreeBSD officially would be worth their time (widespread use in server environments, pillar of Unix-like OSes so will facilitate support to a wide range of OSes, etc...). Explore how the foundation could help them streamline this integration. The items listed by @Thefrank highlight an interesting reality: at this point the remaining challenge / missing bit is adoption by community and ecosystem tools, but this will not happen unless FreeBSD is officially supported. This is sort of a chicken-and-egg problem. I feel the community has done its reasonable part by aligning solutions for the core technical stuff, but that it wouldn't be productive to require the community to solve non-technical corporate problems by hacking around (patching closed-source binaries, begging inclusion in Nugget feeds, lobbying projects to support a platform not officially supported etc...). So I feel a productive action the FreeBSD foundation could take is engage with the corporates at Microsoft to try to convince them to meet the community halfway on this one. |
|
On the other hand, as there's 9 preview1 - any "official" way to get there from VMR and 8 SDK or will we have to go through getting alpha 9 first - this is gonna be a bumpy road again. I've already tried doing crossbuilds without any problems, but for VMR we need |
|
I was under impression that we can just use the port to build 9 using artefacts from 8 and this will give us artifacts for 9. Am I wrong about that? |
|
Reading this state that |
|
This is extremely sad and annoying. This means that I wouldn't be able to maintain the port myself without you guys. Anyone willing to take the maintainership? |
|
For now 8 build fine, even .1 and .2 releases can be build from the same port without any changes (you can bump the port to 8.0.2 btw). As for 9, I need to figure out myself how to bootstrap/build this properly first... |
This is exactly the problem that @sec has already addressed: Cross-building new major versions has become relatively easy in the meantime and I've already done this for .NET 6, 7 and 8. However, this approach isn't suitable for maintaining a FreeBSD dotnet port. But as the Makefile indicates, @arrowd has already created a .NET 8 version of |
These are created from the ports build results by running Artifacts are actually created by the build itself, I only compute checksums and reupload archives. |
Yes, the question was rather to maybe someone from .net team and/or someone who maybe know something about this part - as those artifcats are created as product of VMR build - if those could be created/automated from each repo build somehow etc. I will try to find some time and go through docs etc. trying to produce those artifacts for v9, as getting crossbuild SDK is relative easy right now - then those can be used to easily use port to build 9. |
|
I was able to bootstrap 9 for both x64 and arm64, reading helps and understand what you read helps even more :) The steps that were needed, for future as I will mostly forget:
those should be under
@arrowd - as you are port master - do you think it will make sense to also have Having both SDK and Private.SourceBuilt.Artifacts should be all needed to build new versions of SDK, both for 8 (I've already done builds for 8.0.1 and 8.0.2 just by bumping numbers in Makefile on my machines) and 9 (time will tell). @joperator That's how I got those :) |
Yes, absolutely. Just like we have several LLVM's in Ports, in the same way we can have several .NET's. We indeed should structure these ports to have some common base - this is achieved by so-called As I know nothing of .NET - which version should be default? Or even there should be no default at all? In other words, should we have
Yep, I had a feeling that I was doing something wrong in all that versioning. P.S.
You can use |
|
@sec 's workflow is the better way of approaching too-new dotNET versions.
|
|
@sec I haven't tried it yet, but your instructions sound very promising to me. Thank you very much for investigating this. @arrowd I used your
We should definitely have a |
The important thing here is that all files required for the build should be fetched beforehand. The port should stop accessing network right after
For example, rust ports have a special I guess, we'll need to come up with same machinery for ports that use .NET? Are NuGet package hosted on some centralized CDN where we can fetch them by direct URL? |
For NuGet packages there is nuget.org, which appears to be a CDN, where you can also download them by URL. However, NuGet allows the specification of other so-called packages sources, which is done, for example, in the NuGet.Config files of azure-pipelines-agent. |
|
Hello guys, first, thank you so much for your effort. It's great to see this finally happen. Today, I decided to move some of my personal .NET 8 projects to FreeBSD 14, inside a jail, of course, and then, I got 2 problems: 1st, it was necessary to set then, 2nd, now I'm facing the following issue when I'm running
any idea? Once again, thanks a lot. |
|
@rmszc81 First problem is just the way it is, you have to do it. For the second part, you have two choices:
|
|
@sec Interesting! Since the NuGet packages are generated when building the port, would it be a good idea to add this custom NuGet feed automatically as a post-install script of the package? We could for example copy the relevant packages under Private.SourceBuilt.Artifacts to a location such as: /usr/local/dotnet/nuget and create the .nuget/NuGet/NuGet.Config file pointing to this directory |
|
That's good idea, we could copy FreeBSD specific nuget's after build and add pkg-message informing user to reference this directory in nuget.config - @arrowd what do you think? |
|
Normally these packages are in the |
|
Sounds good. @sec can you make a patch for the port yourself? It should be too hard and you seem to already know what and where to put stuff. |
|
Or set BundleRuntimePacks=true: https://github.com/dotnet/installer/blob/75494d3ada6624c411116d4c6e52daaf49154ee7/src/redist/redist.csproj#L9 |
|
Hello everyone! My solution was to run So far, so good, the project was built, published to As this problem is not related to the .NET framework, I'll go after the solution in the appropriated place. Besides, as my app has support to Anyway, I'd like to say thanks again to @sec, @nkosi23, @akoeplinger and @arrowd for the support. I went through all the links and I found a lot of cool stuff. See you guys around. |
|
As for SQLite, it's old known issue (ericsink/SQLitePCL.raw#176) - simplest you can do is to either create symbolic link |
|
hello @sec, I'll have a look on this in another time. But thanks anyway, you helped a lot already ^^ |
|
Well... As building 8.0.3 was no problem... Then |
If I remember correctly, the FreeBSD 13.3 and 14 both include a Linux-compatible Unfortunately, even though this work was sponsored by the FreeBSD Foundation, it landed without an accompanying man page so you have to poke at the headers and the git history to know that it's there (@emaste, perhaps the Foundation could also sponsor the docs?). Note that, unfortunately, you can't use the header to detect the features that are supported because the header provides a full set of the Linux |
and others
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):
Operation principles:
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.
Related issue(s)
/cc: @janhenke @josteink
The text was updated successfully, but these errors were encountered: