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. |
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. |
|
@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 EDIT: 4 day later update Using the most recent net9 preview tag, runtime/src/tasks/Crossgen2Tasks/ResolveReadyToRunCompilers.cs Lines 116 to 120 in a5cc707 There is no "Property reassignment" note in the binlog when this happens. AFAIK Cross-OS is not supported for R2R or AOT when targeting FreeBSD. The Crossgen2 project seems to honor this as it skips this part during packaging: I will try and work over this a bit more in the coming days and open an actual issue for this instead of burying it in an edit of a long post. |
|
@Thefrank did you cross compile from VMR or from the repo's (runtime, aspnetcore and sdk (as it now contains installer)) ? |
|
@sec AFAIK you can not use VMR for cross compile, but I have never actually tried. I will give it a shot for the most recently published tags. Summary of wall and issue: edit: There is a typo in the tag for this repo: https://github.com/dotnet/runtime/releases/tag/9.0.0-preview.6.24327.7 <- all other tags both here and in other repos contain a leading |
|
I installed .NET 8.0.6 using The application can be run by explicitly launching I've tracked this down to the default install location, per If |
|
@logiclrd should be fixed in net9 #100731 and with this https://reviews.freebsd.org/D44560 |
|
@Thefrank Thanks for the reply :-) I took a look at that PR and I don't think it'll fix the problem at the runtime level. The FreeBSD-specific logic it adds still looks in I don't know how to read Differential (that looks like what it's called?). Does being in that list mean it's already a part of the codebase? It says |
|
@logiclrd That differential is has not been commited. If/when that happens, it will be closed and it will have a commit attached to it in the "Details" section. If you are using your own ports base, you can make the change locally by downloading, ("Download Raw Diff" on the sidebar), applying (via git), and then rebuilding the port. Unless you already maintain a local ports tree, I suggest waiting and continuing to use the workaround when needed. |
|
@Thefrank Maybe .NET 9 installs to a different path than .NET 8... but: This was done with simply |
|
@logiclrd net8 will not contain that fix unless it is manually added via patch from the port maintainer and/or D44560. net9 as of preview 6 does contain the fix. the pkg makes a symlink between the binary location and is why There is currently no net9 pkg |
|
@Thefrank I see that it is a symlink, but it is a symlink to |
|
The fix is not yet into port that install dotnet from pkg. you can set |
|
Taking an opportunity to remind that a proper port maintainer would be great to have. |
|
I have never maintained a port for any system, and the build process here is a bit beyond me. Nevertheless, I am happy to help or take on maintainership with some guidance. We target dotnet on FreeBSD, so this is important to have and worth dedicating work hours to. Given my ignorance mentioned above, would it be worthwhile for me to pursue this? |
|
@greggyb If you want a brutal crash course on port maintenance and enjoy complex technical challenges, you can take a shot but be prepared for a lot of learning... In all honestly I do not think that maintaining the dotnet port is beginner-friendly. Beyond getting around understanding the port system, you also need to be able to debug and fix stuff TheFrank and sec style when things break deep into the the build process because of upstream changes. I've personally struggled to create a port for the ydb database despite the fact that it essentially can be built as is on Unix, just understanding the port system is a task on its own. If you add to this the complexity of building dotnet, it could be overwhelming. That being said, I've heard about folks who maintain hundreds of ports like it's a walk in the park. So maybe I'm just not wired for this but you very well may be. Just my 2 cents! |
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: