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. |
Not at the moment, it'd be great if you do this.
.NET 8 is now in
We can as well strive for that. I guess, we need to strip |
That is great news! I missed that when I glanced over the ports.
There are likely only 3 files that will trip up Everything else gets put into versioned sub-directories by default. |
|
With GHC (a Haskell compiler) I solved it the following way:
What we can do for dotnet is:
|
|
Don't know if that's possible in ports handling, but I think the best options would be to:
We need to have |
https://learn.microsoft.com/en-us/dotnet/core/distribution-packaging#recommended-packages is the recommended dotnet package structure that avoids issues with overwriting shared files. Would it be feasible to follow this package structure on FreeBSD as well? |
No, that's not possible with |
|
Edit after the fact: I am not certain on the stuff below so please fact-check me. Microsoft publishes both a "Dotnet SDK" and a "Dotnet Runtime" (technically multiple). In their topology, the SDK includes the runtimes.
# pkg install dotnet-sdk # not very useful yet
# pkg install dotnet-runtime8 # now can develop and run targeting dotnet8, incl ASP.NET and Desktop runtimes
# pkg install dotnet-core-runtime9 # now can additionally develop and run console apps targeting dotnet9, but not ASP.NET or Desktop
I am assuming, here, that the
This would still provide the guarantee that if someone explicitly installs dotnetX (or runtimes), that they would never lose that in the course of a |
dotnet binary is the interface to both the runtime and SDK. dotnet binary, runtime, ASP.NET, no SDK is very typical deployment configuration for .NET cloud apps. |
|
Thank you for the clarification there. Given that, it seems my first suggestion is no good, but I think the second path I laid out still makes sense in terms of packaging within the constraints of FreeBSD's Thoughts? |
It looks like a subset of the scheme described at https://learn.microsoft.com/en-us/dotnet/core/distribution-packaging#recommended-packages (with different names). Is there a good reason for inventing your own scheme for FreeBSD instead of just using the same scheme as Linux? |
|
@jkotas my understanding is that the scheme you link to is actually being used by the FreeBSD port, the only problem is with the dotnet binary file, since all versions of .net install it to the same path while it is not possible to install 2 FreeBSD packages that would try to install a file to the same path. Thus the solution proposed by @arrowd which looks like a simple and elegant way to address the issue. Alternatively, we could also have dotnetX and dotnetX-lib ports where the lib ports do not have the executable. |
The Linux scheme addresses the problem with shared file by |
|
@jkotas Oh I didn't realize that there is the disk layout but also a recommended way to structure packages. I only meant that the disk layout is being followed by the port. However in terms of packaging, everything is included in a single package for time being from what I can see. As for why, I have to let others answer, but I guess it's just a matter of the initial effort was focused on getting a basic port ready which was already a challenging task in itself. And if it wasn't for the issue with the dotnet exec, it wasn't necessarily clear that breaking down the port into multiple packages would bring something to the table. I am not sure how difficult it would be to break the port into multiple packages. Maybe the port system has a feature to facilitate creating multiple packages from the same build. Otherwise the task could be time consuming. |
Probably not. To speak only for myself and no one else, I was responding from ignorance without researching enough (or reading the link you had shared before I posted). I saw the issue described upthread about a bump to the single dotnet package for FreeBSD breaking deployed applications and the constraint about packages with conflicting files. I then went straight to brainstorming (again without referencing your link), not really thinking about the fact that this is probably solved by several Linux distributions already. It's heartening to me, though, that I came up with an outline that matches that current best practice, at least in the broad strokes (: |
|
So to make this simply visible, idea is to have:
installing only @arrowd that should be doable using ports, right? |
|
@sec shouldn't |
True, that's why I wrote |
|
Right now each port's build produces a single package. This means that if we are to have The ability to produce multiple packages from a single build is provided by a feature called subpackages, which is currently only partially implemented. I'd wait for a full subpackages support in Ports first, before implementing the decomposition you're proposing. For now I think we should just make dotnet8 and dotnet coinstallable by removing conflicting files. |
|
Fair, so how would you see having those 3 files coinstallable? We can't remove them from dotnet8 port and install only with dotnet9, as not having dotnet binary will make it useless. |
|
In an attempt to summarize and provide some decision-points: It seems like we agree in this thread that there is a correct long-term solution, summarized in @sec's #14537 (comment) With today's There is a future feature in Thus we are left with a decision between several candidates for a sub-optimal short-term approaches: A. Adopt the long-term package topology today at extra cost: Build I think this covers the short-term approaches discussed, modulo some naming conventions. Some important questions that arise here:
|
|
I think (assuming I am correct) in runtime |
exactly, building just |
Why useless?
I'd go for it as it looks optimal in time/gains terms. However,
also sounds good, but does upstream expect it to be built and packaged this way? I know nothing of .NET ecosystem and was thinking that the only supported way to build all this stuff is VMR. |
VMR is the only way to offline/sourcebuild. This is the only way for ports to build dotNET without a great deal of extra work. Online builds can be done via each repo and pulled together at the SDK for a binary package. This a good way to get a bootstrap binary if none is available. This still requires some amount of juggling outputs into inputs but at this point is rather painless. Very few things build without a working dotNET SDK; the edit: |
|
I think we should stop using this issue as a chat. How about migrating into Matrix or Discord? I can try arranging a room on the FreeBSD Matrix Dev server. |
Makes sense :) Fine with Discord or Libera also. |
|
Please join https://matrix.to/#/!RzOryqYAIqxaAmbYDE:matrix-dev.freebsd.org?via=matrix-dev.freebsd.org |
|
Does anyone know, if it's possible to include extra nupkg's that get bundled with vmr build under |
|
@sec The VMR should already bundle runtime packs and ILC into the SDK. This leaves just the Crossgen2 NuGet. AFAIK there is no way to bundle it automatically. |
|
@arrowd @Thefrank I've made dotnet-host port and made changes for 8/9. I've tried install/build with dotnet. dotnet8 running in the background - I assume it will fail to install side-by-side, as there are some more packs in both releases. I've did quick add, to include all freebsd nupkg into library-packs (even some of those are already in there) - we could handpick Crossgen2 for example, but maybe having them all, won't hurt? edit: here's the link :P sec/freebsd-ports@785055f |
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: