-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On porting .NET Core to FreeBSD #10355
Comments
@mateusrodrigues that sounds like an exciting project! I'll be happy to support you in your effort. I've brought up support for Alpine Linux in all of our repos end to end and also fixed several build issues on the FreeBSD native side in the past. @wfurt has recently done some work on fixing various managed components to work on FreeBSD properly.
The .so files you get on Windows are smaller because they are a release build stripped of all debugging symbols. They are not built on Windows, but rather extracted from NuGet packages. The .so files you build on Linux or FreeBSD are not stripped, which makes them about 10x larger, as you've mentioned.
Putting together a working runtime is more involved than what you did. The easiest way to start is to use the bootstrap CLI creation script that I have written some time ago. You can find it here: https://github.com/dotnet/source-build/blob/dev/release/2.1/scripts/bootstrap/buildbootstrapcli.sh I've tried to use the script on FreeBSD in the past and it worked for the native components build (but I needed to do a couple of hacks in it to fix few things - @wfurt would know better since he's worked more with it on FreeBSD). As for managed components that you need to replace for FreeBSD too, you'll need to build them on Linux or Windows and then copy them over the same files in the CLI package. @wfurt should be able to tell you which ones you need. Once you get the bootstrap CLI, you can use it for building managed components in coreclr, corefx and core-setup repos right on FreeBSD or just to build applications on FreeBSD. Now it would be interesting to know what is the exact purpose of your project. If the goal is to integrate the end to end build into the FreeBSD so that FreeBSD native packages are produced, then it might be better to work in the https://github.com/dotnet/source-build repo. The goal of that project is to make the whole runtime buildable from scratch from sources of coreclr, corefx, core-setup and some other repos. However, it is still an effort in progress. @weshaggard should be able to tell you whether it is already in a state when you could base your work on that. |
@janvorli Awesome, thanks for your answer. As I'm working on a somewhat tight schedule, the main idea here is to have enough of the .NET Core SDK ported so that I can build PowerShell Core for FreeBSD. I'm still a little in the dark as to how much of the SDK should be ported, so I'm starting with the minimal: runtime first, then SDK tooling. But, after this project is completed, I do plan to work on porting the whole thing over so that FreeBSD becomes yet another option for us .NET developers to write .NET Core software. I'll work on the information you provided and continue discussion on any further progress I achieve 😃 |
@mateusrodrigues in that case, the bootstrap CLI creation as I've mentioned above should give you the fastest way to get PowerShell working. |
Did you look at the instructions here: https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD @mateusrodrigues ? CoreCLR and CoreFX no longer builds for me but that should be easy to fix. With that working we were able to pass most of the tests as well as run simple SDK functions. As of 2.1 I was also able to run Linux SDK on FreeBSD 11 under Linux emulation. I'll look at my projects and I'll push out fixes I have so far to at least get to point we can build and instructions are valid. |
@mateusrodrigues, @eerhardt has discovered today few discrepancies in the doc and the script options. First, the script help describes an option |
Also related https://github.com/dotnet/coreclr/issues/15674. |
@wfurt Yes, I followed those, although not on the current master branches, I used the 2.1.0 RC1 release. It doesn't build as well, still have to investigate further as to why. But I'll try again later with your PR dotnet/coreclr#18072. @janvorli It took me a while but I was able to figure that one out 😄 I've been documenting the commands I'm running and, if it hasn't been done yet, I can submit some PRs correcting the existing docs. |
@mateusrodrigues - I put up dotnet/source-build#568 to fix the incorrect places I found in the bootstrap documentation. Please feel free to submit more as you find them :) |
CoreCLR should build again. CoreFX build issue is tracked by #29841. BTW targeting Linux may give you 'hello world'. But you cannot get working product on FreeBSD. |
@wfurt Yes! CoreCLR and CoreFX are now building on FreeBSD! |
yes. using build constructs like "-os=Linux" or copying .dll assembly from Linux version. It also impacts test runs. Using -SkipTests is quick ay around it, but if we want to productize it, fixing tests and production code is great way to start. It would be also nice to update documents as need - both dated CoreCLR FreeBSD doc as well as living WIKI document. I don't know what is your exact plan @mateusrodrigues but I can give you ordered list of tasks I think needs to be done in order to productize this - or at least get it to point we can have daily CM runs. |
@wfurt The plan for this project is to port the .NET Core SDK over to FreeBSD so that I can build and utilize PowerShell Core on the platform. So yes, a production-ready product would be ideal and is my ultimate goal, specially since we're doing this in order to push the bits over to the ports tree and to the But as I'm working on a tight schedule (GSoC will last up to early August), the way I'm going about this is to get to a point where I have PowerShell running (even if roughly) and then work my way back fixing things around, passing all the tests, and writing the ports. But right now, I'm just looking for a fast way to get there -- my objectives with this fast-lane-first approach is a better understanding of the whole build process and actually having a proof-of-concept working. So, you can go ahead and send me the list, it certainly would be of great help once I get to the point of actually productizing this. Also, even though I'm trying to go fast, I wasn't planning on actually using Linux versions of .NET, but trying to build a native FreeBSD-supported one. For this, I'm looking at the bootstrap CLI script in the source-build repository @janvorli mentioned. I hope this helps understanding my plan better 😄 I hope it's a good one also! |
@wfurt @mateusrodrigues hey, if it's not a problem, could you also post this list somewhere online - I'm sure there are lots of BSD fans that can help if needed with some tasks, as we all would love to have fully working .net core on best OS :) |
There used to be CI job for FreeBSD in CoreCLR, which was removed because things weren't moving forward. |
I sent @mateusrodrigues private email @sec and maybe he can track tasks on his project page. |
Awesome to see @mateusrodrigues working to get PowerShell Core working on FreeBSD! Once you get the coreclr/corefx components working, open an issue on PowerShell repo if you hit problems compiling the PowerShell Core code and I can help out. |
hello @mateusrodrigues , did you have chance to look at my email task list or suggestions from @sec |
Hello @wfurt @sec sorry for the delayed answer, I've been busy with school finals. I just uploaded the priority list over at my gsoc18-progress repo, you can check it out here. I will work on item 1 today and report any blocking issues. @SteveL-MSFT Will do! Thanks for reaching out! |
Hi, everyone! An update on the progress of the port: I managed to bootstrap the .NET SDK for FreeBSD using @janvorli's script with all native components building and it's available here. Here are some observations about it:
On this last issue, when I run
And interrupting the execution spits out this perf summary, take a look at the last line there:
Can anyone shed a light on what might be happening here? |
It appears the compiler (
That should print a message asking for inputs. Another thing to try is to turn off shared compilation, to see if that's the problem. You can do that by setting the env variable <PropertyGroup>
<UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup> |
Looks like shared compilation is the problem. I altered the |
The I assume something in the inter-process communication (sockets or pipes? - I'm not sure which is being used) isn't working, causing the compiler to hang. @agocke and @jaredpar should be able to help give you some steps on how to debug the issue. Maybe using |
A debugger would be useful, but I presume that's not easily available on FreeBSD. We do have an environment variable, |
sos plugin should work as well as 'truss' as equivalent of strace. |
BTW is there any OS specific code in Roslyn @agocke? I had to make some fixes in msbuild last year as it did not handle unknown (FreeeBSD) platform well. |
Either that (likely NamedPipeClient/ServerStream, which uses unix domain sockets), or some interaction with Process, which also has a lot of Linux-specific and macOS-specific code. |
I can try to run NamedPipe corefx tests. Process management is new for FreeBSD .. and there can be some bugs. |
I think most of our Linux behavior checks should be POSIX compliant. I would expect the named pipe stuff to be far more fragile. |
One thing that has caused hangs in the past is handles being inherited that are then waited on by one of the child processes. I believe the chain required three nested processes, where the innermost was waiting on the outermost, or something similar. On Windows we call CreateProcess with P/Invoke to prevent dangling handles. On Unix we can't P/Invoke, so we try to redirect I/O in every subprocess, hopefully preventing the child processes from catching the I/O from a parent process. |
Yes, that's likely it then. This is the test for the mutexes I was talking about. |
A bit more information on my last comment. This is the error message I get for the
|
I can pass the tests successfully if I force as far as the notes from @agocke:
I see trace like:
The 7112 is trying to connect and it will eventually succeed. Both sides would make the socket non-blockinbg but there is no other activity after. no attempt to read or write. With SOCK_CLOEXEC set, there should be no inheritance problems (as well as I would see them my trace) I looked at the Pipe code in corefx and all looks reasonable to me. |
I talk to @agocke today and I think I understand what the build expects and what is not working. |
It seems like the problem was in processing kqueue events on FreeBSD. I made some changes to networking_pal in corefx and I was able to build completely coreclr and few other repos from source-build using bootstrap cli. msbuild and Roslyn seems to function without any observed problems. Named pipes tests from corefx now all pass. all pal tests form coreclr pass. sos plugin works and can be used to debug managed code. corefx still fails to build because of some package/parameter mismatch. I'll dig into this next. |
Currently failing CoreFX tests on FreeBSD
With OuterLoop enabled
|
Thanks @mateusrodrigues for good summary. Do you have IPv6 enabled? Without it many tests will fail. That is just implicit assumption. |
If you're not already, you probably also want to run tests with /p:OuterLoop=true, as there are many tests categorized as "outer loop" that don't run by default. |
@stephentoub If I ran it correctly - |
Thanks |
Hi @mateusrodrigues. I was not abe to reproduce System.Net.NameResolution* failures. System.Xml.Xsl.XslTransformApi.Tests.dll would fail for me only when platform is incorrectly set to Linux in RunTests.sh. Please make sure category is set to nonfreebsd. System.IO.MemoryMappedFiles.Tests.dll failure may be test issue. It expects generic IO exception but it will get arguments exception about filename too long.
|
I opened https://github.com/dotnet/corefx/issues/30899 for System.IO.FileSystem.Tests failures. |
Hi @wfurt, so here's what I've got:
|
@Szadegan, that means that the linker was killed, it is likely that it has happened due to an excessive memory consumption. How much physical memory / swap space does your machine have? And how much of free memory was available before the build? |
BTW I tried about two weeks ago and coreclr build was broken again. I did not have a time to look at it and fix it. |
@janvorli The memory is 1GB which was written its enough. But that really might be the issue since its a small VM on Azure. Will try it again then on a better machine :) thanks |
is this done, as GSoC have ended? |
Here's an update for you guys: the ports for dotnet and powershell have been submitted and are currently under review. There are changes I still need to upload, I'm working on them to do that as soon as possible. Right now, dotnet is building native components on the machine, however the managed parts are being downloaded pre-built - for the time being. Powershell is being built entirely locally on the machine. Next steps, for the most part, include porting source-build to make the build process easier, since the dotnet-sdk port builds coreclr/corefx native, but downloads all other SDK components pre-built from the internet. Conversation on the port is happening here. cc @sec |
Good news :) |
The PR seems completely abandoned - no updates for months. |
The active FreeBSD-related conversations are happening elsewhere: https://github.com/dotnet/corefx/issues/1626 or https://github.com/dotnet/core-setup/issues/5083 |
Maybe this one should be closed. One can alway do query with os-FreeBSD label for coreclr and corefx to get list of current issues. Progress is slow, mostly reactive to reported issues like dotnet/coreclr#22124. |
Closing this issue. Will keep an eye for os-FreeBSD labeled ones. |
Hello,
I'm working on a project with Google Summer of Code and FreeBSD to port the .NET Core runtime and SDK, as well as PowerShell, over to the FreeBSD platform. Right now, I'm gathering information on how to build and put together the tooling and runtime, since the components are pretty scattered around in different repositories.
I've started with CoreCLR and CoreFX to build a working runtime, which I'm basing on the 2.1.0 RC1 release -- commit hash
a226c35
for CoreCLR and8f968b9
for CoreFX. What I did was building them on Ubuntu Linux (which is an officially supported platform) to understand what the build results are and how to put them together, and then execute the same steps on FreeBSD to try to get the same result. During this process of building on Linux, I've come upon a couple questions which I'd like to discuss:I've built the CoreFX managed components on Windows (targeting Linux with
build-managed.cmd -os=Linux -SkipTests
), which resulted in a bunch of DLLs (exptected) and a couple Linux executables and .so files (not expected). These executables and .so files also appear when building CoreCLR native on Linux, which is expected. Why did they appear on the Windows build and which ones should I use, the ones that appear on the Windows CoreFX managed build or the ones that appear on the CoreCLR native build? They have the same filenames but different sizes -- the ones on the CoreCLR native build are about 10x larger.After getting the runtime working on Linux by creating the folder structure with the dotnet executable on top, the
libhostfxr.so
file inside thehost/fxr/2.1.0-rc1
folder and the DLLs along withcreatedump
and the native components of CoreFX inside theshared/Microsoft.NETCore.App/2.1.0-rc1
folder, I tried executing a little HelloWorld.dll program I created and built elsewhere on my own built-from-source runtime and it complained about a missing Microsoft.NETCore.App.deps.json file. In what step should it get built and how do I build it?cc @Petermarcu @jkotas
I should mention this project is being mentored by @DragonSA (FreeBSD) and @davidchisnall (Microsoft Research and FreeBSD)
The text was updated successfully, but these errors were encountered: