Skip to content
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

add support for FreeBSD cross-compilation #34000

Merged
merged 16 commits into from
Mar 31, 2020
Merged

Conversation

wfurt
Copy link
Member

@wfurt wfurt commented Mar 24, 2020

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.

eng/native/init-distro-rid.sh Outdated Show resolved Hide resolved
@wfurt wfurt requested a review from sdmaclea March 25, 2020 02:26
Copy link
Contributor

@sdmaclea sdmaclea left a comment

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.

eng/native/configureplatform.cmake Outdated Show resolved Hide resolved
eng/native/configureplatform.cmake Outdated Show resolved Hide resolved
eng/native/configureplatform.cmake Outdated Show resolved Hide resolved
src/coreclr/crossgen-corelib.sh Outdated Show resolved Hide resolved
src/coreclr/crossgen-corelib.proj Outdated Show resolved Hide resolved
src/coreclr/src/dlls/mscordac/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/dlls/mscordac/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/dlls/mscordbi/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/pal/src/libunwind/src/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/tryrun.cmake Outdated Show resolved Hide resolved
@wfurt
Copy link
Member Author

wfurt commented Mar 25, 2020

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
Copy link
Member Author

wfurt commented Mar 25, 2020

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
Copy link
Contributor

sdmaclea commented Mar 25, 2020

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
Contributor

Where is that definition?

see
#1887 (comment)

@sdmaclea
Copy link
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.

src/coreclr/runtime.proj Outdated Show resolved Hide resolved
@wfurt
Copy link
Member Author

wfurt commented Mar 26, 2020

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

src/libraries/Native/Unix/configure.cmake Outdated Show resolved Hide resolved
@@ -1,4 +1,5 @@
set(TARGET_ARCH_NAME $ENV{TARGET_BUILD_ARCH})
set(CROSS_ROOTFS $ENV{ROOTFS_DIR})
Copy link
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
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.

@am11
Copy link
Member

am11 commented Mar 31, 2020

@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
Copy link
Member Author

wfurt commented Mar 31, 2020

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
Copy link
Member Author

wfurt commented Mar 31, 2020

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
Copy link
Member

ericstj commented Apr 1, 2020

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

@am11
Copy link
Member

am11 commented Apr 1, 2020

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
Copy link
Member

jkotas commented Apr 1, 2020

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
Copy link
Member

jaredpar commented Apr 1, 2020

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