Initial support for FreeBSD. #1362

wfurt · 2019-11-13T10:28:08Z

contributes to #1139.
With limited ability to commit to repose, I focus on passing parameters to the build.
Using patches when necessary.

cc: @joperator @jasonpugsley @am11

omajid · 2019-11-13T14:35:35Z

patches/corefx/0006-Do-not-fail-on-test-chmod.patch

+           UseHardlinksIfPossible="$(UseHardlink)" />
+
+-    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension)" Condition="'$(OS)' != 'Windows_NT'"/>
+    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension) || true" Condition="'$(OS)' != 'Windows_NT'"/>


Has someone from corefx looked at this change? We are (or were) hitting this on Fedora 32 and Arch Linux as well: #1310 (comment). Maybe this should be merged into corefx if it's the correct general fix.

yes, that is my plan. but I'll do it after repo merge. I did testing and we don't need it at all any more. The dotnet is executable as it should on its own.

Does the build work without this change? I wouldn't expect test code to be getting hit in our normal build.

@crummel The build fails here for Fedora 32 and Arch Linux too: #1310 (comment). This code path is definitely invoked in source-build.

no, it does not build @crummel
It seems like it got moved to Arcade in master.
I'll take a look after repo merge is over.
cc: @safern

BTW I think this is old time paranoia when we did not know how to set and preserve executable bits on Unix.

am11 · 2019-11-13T14:38:18Z

patches/corefx/0006-Do-not-fail-on-test-chmod.patch

+           UseHardlinksIfPossible="$(UseHardlink)" />
+
+-    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension)" Condition="'$(OS)' != 'Windows_NT'"/>
+    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension) || true" Condition="'$(OS)' != 'Windows_NT'"/>


(In foreseeable future) Would it be possible to prepare TestHostRoot directory before executing the build.sh? How do the other platforms acquire it?

I had to figure out what constituents are required in this directory to execute corefx tests.

This normally comes from TestHost and matching runtime entry. The problem is that if you get standard package (or if it lives in your nuget cache) it does not have platform reference and then dotnet is not restored and chmod fails.
At this point you may not even want to run tests but it breaks build it self. Conceptually I feel that is not correct.
To get to point where you can run tests on FreeBSD, I copy bootstrap dotnet over. (and related native libraries) You can pass --buildtests to top level script to build but not run tests @am11. This will go away and everything will work as other platforms once we have builds and packages flowing.

wfurt · 2019-11-13T20:17:55Z

OSX failures seems like infrastructure issue

It was not possible to find any compatible framework version
  The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
    - Check application dependencies and target a framework version installed at:
        /Users/runner/.dotnet

crummel · 2019-11-13T21:16:13Z

Yup, OSX failure is expected, I'm looking at it.

crummel

One question on the test change patch, but looks good to me overall.

crummel · 2019-11-13T21:20:22Z

patches/corefx/0006-Do-not-fail-on-test-chmod.patch

+           UseHardlinksIfPossible="$(UseHardlink)" />
+
+-    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension)" Condition="'$(OS)' != 'Windows_NT'"/>
+    <Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension) || true" Condition="'$(OS)' != 'Windows_NT'"/>


Does the build work without this change? I wouldn't expect test code to be getting hit in our normal build.

…into freebsd3

crummel · 2019-11-15T19:50:48Z

@wfurt Is this ready to go in?

omajid · 2019-11-15T20:10:38Z

repos/vstest.proj


  <PropertyGroup>
+    <OverrideTargetRid>$(TargetRid)</OverrideTargetRid>
+    <OverrideTargetRid Condition="'$(TargetOS)' == 'FreeBSD'">freebsd-x64</OverrideTargetRid>


Sorry if this is already obvious to everyone else, but what is the original value of TargetRid here that's being overridden?

We generate this at the very beginning of the build here:

source-build/tools-local/init-build.proj

Line 111 in 8ebb121

<Target Name="WriteDynamicPropsToStaticPropsFiles">

That calls into our task which in turn is calling into core-setup code to get the RID the same way the product does. This will by default be a non-portable RID but it looks like FreeBSD, like Windows and OSX, always uses a portable RID - @wfurt will have to be the one to explain if you're interested in why that is.

Oh, so this is just forcing a portable RID instead of the non-portable RID? That answers my question.

Yes, that's correct.

yes, we decided that last year but that change never made it to all repose. Also repos now are inconsistent so source-build is the glue to force same and expect RID.
One day we should make it simpler but for now we do want portable RID as all versions are binary and API compatible. (at least for parts we need)

wfurt · 2019-11-15T23:00:11Z

it would be great if anybody can confirm that this works. But this should be good to go as it works at least in cases I tested and it does not break other platforms.

crummel · 2019-11-18T21:14:13Z

@dseefeld think we can go ahead with this? we can't verify that it remains working without CI but it doesn't seem to break anything else.

dseefeld · 2019-11-18T21:17:25Z

@dseefeld think we can go ahead with this? we can't verify that it remains working without CI but it doesn't seem to break anything else.

Yes. I think we should merge this.

wfurt added 2 commits November 12, 2019 19:36

staging

aca9dc8

update

9471b34

wfurt requested review from crummel and omajid November 13, 2019 10:28

wfurt self-assigned this Nov 13, 2019

omajid reviewed Nov 13, 2019

View reviewed changes

am11 reviewed Nov 13, 2019

View reviewed changes

crummel requested a review from dseefeld November 13, 2019 21:15

crummel reviewed Nov 13, 2019

View reviewed changes

wfurt added 3 commits November 13, 2019 14:11

one more fix for core-setup

f9f3d45

fix few more places with RID mismatch

8fefb1a

fix aspnetcore

c9bf890

wfurt mentioned this pull request Nov 14, 2019

Building the .NET Core SDK on FreeBSD #1139

Closed

wfurt added 2 commits November 14, 2019 18:25

fix fsharp

34d7398

Merge branch 'release/2.0' of https://github.com/dotnet/source-build …

d1dbb1e

…into freebsd3

omajid reviewed Nov 15, 2019

View reviewed changes

crummel merged commit feb9d91 into dotnet:release/3.0 Nov 18, 2019

crummel pushed a commit to crummel/dotnet_source-build that referenced this pull request Nov 21, 2019

Initial support for FreeBSD. (dotnet#1362)

b6d7db5

MichaelSimons mentioned this pull request May 19, 2021

Arcade powered source build dotnet/aspnetcore#32790

Merged

Initial support for FreeBSD. #1362

Initial support for FreeBSD. #1362

Uh oh!

Conversation

wfurt commented Nov 13, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfurt commented Nov 13, 2019

Uh oh!

crummel commented Nov 13, 2019

Uh oh!

crummel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crummel commented Nov 15, 2019

Uh oh!

omajid Nov 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfurt commented Nov 15, 2019

Uh oh!

crummel commented Nov 18, 2019

Uh oh!

dseefeld commented Nov 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

omajid Nov 15, 2019 •

edited

Loading