Skip to content

add support for FreeBSD cross-compilation - #34000

Merged
wfurt merged 16 commits into
dotnet:masterfrom
wfurt:freebsdCross2
Mar 31, 2020
Merged

add support for FreeBSD cross-compilation#34000
wfurt merged 16 commits into
dotnet:masterfrom
wfurt:freebsdCross2

Conversation

@wfurt

@wfurt wfurt commented Mar 24, 2020

Copy link
Copy Markdown
Member

This change allows to cross-compile FreeBSD on Linux using ./build.sh -cross -os FreeBSD
(depends on dotnet/arcade#5114 and dotnet/arcade#5100)

In general, this is using existing cross-compilation support. However, when we cross-compile for different CPU architecture, we can use host and target somewhat interchangeably. As we build arm Linux on x64 Linux) With this we need cleaner (and correct) separation. With the example above, __HostOS and CLR_CMAKE_HOST_OS is set to Linux while __TargetOS and CLR_CMAKE_TARGET_OS is set to FreeBSD. With that in mind, CLR_CMAKE_HOST_LINUX should not be used to determine target options as well as created binaries are not runnable on host even if CPU architecture is same.

-fuse-ld=lld is no longer needed with clang90 - both native and cross-compiled build.

So far there is no CI. I did verify that generated pal/src/config.h is identical with one produced by running native build on FreeBSD.

@wfurt wfurt self-assigned this Mar 24, 2020
Comment thread eng/native/init-distro-rid.sh
Comment thread eng/native/init-distro-rid.sh Outdated
Comment thread src/coreclr/src/pal/src/configure.cmake Outdated
Comment thread docs/workflow/building/libraries/freebsd-instructions.md Outdated
Comment thread src/coreclr/src/dlls/mscordac/CMakeLists.txt Outdated
Comment thread src/coreclr/src/pal/src/CMakeLists.txt
Comment thread src/coreclr/src/pal/src/configure.cmake
@wfurt
wfurt requested a review from sdmaclea March 25, 2020 02:26

@sdmaclea sdmaclea left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is a misunderstanding on the intended purpose of Host and Target.

We are using the gcc/gdb/llvm/lldb model for the definitions of Build, Host, Target.

Build the OS that the compiler is running on.
Host the OS of the machine where the compiled code will run.
Target the machine the which the running code will compile/debug.

In most cases TargetOS == HostOS. We have a few components which run on a different machine than their target. So far these are code generation and debug tools. For example we have a crossgen which can run on x64, but generate code for Arm64. I am also working on debugger tools which will run on Windows but debug a Linux runtime.

I think you are just trying to enable cross compilation of the runtime on Linux targeting FreeBSD. In this case the HostOS and the TargetOS should both be set to FreeBSD.

Comment thread eng/native/configureplatform.cmake Outdated
Comment thread eng/native/configureplatform.cmake Outdated
Comment thread eng/native/configureplatform.cmake Outdated
Comment thread src/coreclr/crossgen-corelib.sh Outdated
Comment thread src/coreclr/crossgen-corelib.proj Outdated
Comment thread src/coreclr/src/dlls/mscordac/CMakeLists.txt Outdated
Comment thread src/coreclr/src/dlls/mscordac/CMakeLists.txt Outdated
Comment thread src/coreclr/src/dlls/mscordbi/CMakeLists.txt Outdated
Comment thread src/coreclr/src/pal/src/libunwind/src/CMakeLists.txt
Comment thread src/coreclr/tryrun.cmake Outdated
@wfurt

wfurt commented Mar 25, 2020

Copy link
Copy Markdown
Member Author

We are using the gcc/gdb/llvm/lldb model for the definitions of Build, Host, Target.

Where is that definition? I only see use of Host and Target OS and ARCH through out the project files. And we already for example build Linux on Windows.

@wfurt

wfurt commented Mar 25, 2020

Copy link
Copy Markdown
Member Author

I check and for the `linuxdac' target on Windows and I see CLR_CMAKE_HOST_OS=Windows_NT and CLR_CMAKE_TARGET_OS=Linux. (CLR_CMAKE_BUILD_OS is not set)

@sdmaclea

sdmaclea commented Mar 25, 2020

Copy link
Copy Markdown
Contributor

I check and for the `linuxdac' target on Windows and I see CLR_CMAKE_HOST_OS=Windows_NT and CLR_CMAKE_TARGET_OS=Linux. (CLR_CMAKE_BUILD_OS is not set)

Yes. That command line option builds a DAC on a Windows build machine that runs on a Windows host to debug a Linux target runtime.

There is very little mention of Build in the make system so far. In general, the Build machine has made little difference.

/cc @jkotas.

@sdmaclea

Copy link
Copy Markdown
Contributor

Where is that definition?

see
#1887 (comment)

@sdmaclea

Copy link
Copy Markdown
Contributor

One source of confusion is that by default Build machine properties sets the Host variables.... This is due to the simple assumption that in many cases Build == Host == Target.

Comment thread src/coreclr/crossgen-corelib.proj Outdated
Comment thread src/coreclr/runtime.proj Outdated
Comment thread src/installer/corehost/build.proj Outdated
Comment thread src/coreclr/crossgen-corelib.sh Outdated
@wfurt

wfurt commented Mar 26, 2020

Copy link
Copy Markdown
Member Author

This should be hopefully ready for final pass. I made change @jkotas suggested to always pass -os the the shell script. I also did basic verification that produced binaries do run (on FreeBSD 12.0p9)

[furt@daemon /tmp/dotnet]$ ./dotnet --info

Host (useful for support):
  Version: 5.0.0-dev
  Commit:  a288211ca0

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.NETCore.App 5.0.0-dev [/tmp/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
[furt@daemon /tmp/dotnet]$ ./dotnet --info

Host (useful for support):
  Version: 5.0.0-dev
  Commit:  a288211ca0

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.NETCore.App 5.0.0-dev [/tmp/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Comment thread src/libraries/Native/Unix/configure.cmake
@@ -1,4 +1,5 @@
set(TARGET_ARCH_NAME $ENV{TARGET_BUILD_ARCH})
set(CROSS_ROOTFS $ENV{ROOTFS_DIR})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this already set by eng/common/cross/toolchain.cmake ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does not seems to be set soon enough and build fails. src/coreclr/tryrun.cmake has same line.

Comment thread src/installer/Directory.Build.props Outdated
@am11

am11 commented Mar 31, 2020

Copy link
Copy Markdown
Member

@wfurt, @janvorli, a related question:

In order to support non-Linux/macOS Unix, the requirements are:

  1. build the runtime native components targeting the OS of interest (cross compile or on-device)
  2. build the managed components using crossgen with RID=<TargetOSName>-<TargetOSArch> on a supported OS like Ubuntu, so the TargetOS-specific managed partial classes get compiled correctly.
  3. acquire dotnet SDK tarball for Linux (matching the exact git commit SHA-1)
  4. replace native + managed assemblies from artifacts/ directory to dotnet. This should give us the bootstrap cli, right?
  5. using this (bootstrap, stage-0) CLI, build the source-build tarball

With this PR changes, would we be able to get #1 and #2 using:

./build.sh -cross -os FreeBSD -configuration Release

such that the produced artifacts/ directory has everything ready for drop-in replacement for step #4?

@wfurt

wfurt commented Mar 31, 2020

Copy link
Copy Markdown
Member Author

perf leg failure seems unrelated.

@wfurt
wfurt merged commit 595a95c into dotnet:master Mar 31, 2020
@wfurt
wfurt deleted the freebsdCross2 branch March 31, 2020 20:36
@wfurt

wfurt commented Mar 31, 2020

Copy link
Copy Markdown
Member Author

such that the produced artifacts/ directory has everything ready for drop-in replacement for step #4?

yes, I think so.
In my (debug) case I used artifacts/packages/Debug/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz. That should be complete drop AFAIK.

for #3 all you needs to do is to avoid cross-genned or use environmental variables to suppress R2R.

I was planning to feed cross-compiled runtime + SDK back to source-build. That may be good test.

@ericstj

ericstj commented Apr 1, 2020

Copy link
Copy Markdown
Member

This change appears to be causing failures in all PRs due to passing -os in cases where it isn't supported.

@am11

am11 commented Apr 1, 2020

Copy link
Copy Markdown
Member

Looks like Build Windows_NT x86 release Runtime_Debug leg which also failed to build in this PR. src/coreclr/build-runtime.sh supports -os, but src/coreclr/build-runtime.cmd is missing it. I think the fix would be to add an -os option at

if /i "%1" == "-alpinedac" (set __BuildNative=0&set __BuildCrossArchNative=1&set __CrossArch=x64&set __TargetOS=alpine&set processedArgs=!processedArgs! %1&shift&goto Arg_Loop)

@jkotas

jkotas commented Apr 1, 2020

Copy link
Copy Markdown
Member

perf leg failure seems unrelated.

@wfurt The link to the issue tracking the unrelated failure should be added next time. https://github.com/dotnet/runtime/blob/master/docs/pr-guide.md#what-to-do-if-you-determine-the-failure-is-unrelated

@jaredpar

jaredpar commented Apr 1, 2020

Copy link
Copy Markdown
Member

runtime-live-build (Build Windows_NT x86 release Runtime_Debug) Build Wi

This leg was also failing and was not addressed in the justification for merging.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants