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. |
|
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 |
|
So as the SDK does not accept "General Support" via issues... How is the installer built now that the Installer repo is gone for all versions of dotNET? The SDK has always come across as "magic" to me. From the old installer repo: |
The branches for shipped version of .NET are still there and in use. |
|
ah! I see my mistake. I was tracking SDK branches until a new one would come up, then follow that: 6.0.1xx -> 6.0.2xx -> etc. I was looking for a 6.0.423 which does not exist. From the core repo I see it only lists a 6.0.1xx branch for the SDK and there is a 6.0.131 in the installer repo even though it is unlisted in core. I will give this a shot! pointy hat squarely on me here. |
|
Can we update the OP with what's left of the to-do list on this? I'm definitely interested in contributing if I can, especially considering that I personally want to see BSD support. There was a post here which aggregated a to-do list, but it has everything completed. |
|
A quick summary of
os-freebsd
Documentation:
Implementation:
No issue but mentioned:
Pending PRs:
Others I missed? |
WALL OF STUFF WARNINGdotNET9 preview 5 cross compiles from linux with two small caveats:
neither of these work without external NuGet packages.
Other than Linux ELFs in FreeBSD packs everything is going smooth from the cross compile side for .net 9 |
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: