Skip to content

Latest commit

 

History

History
120 lines (86 loc) · 3.7 KB

DotnetCore-Src.md

File metadata and controls

120 lines (86 loc) · 3.7 KB

DotNet Core Source Builds

I've experimented with building .net core from source and put some notes together below for trying to build under gentoo. Hopefully these might be useful for a future source based ebuild.

make sure to use llvm/clang 4.0.1 not 5.0.1 which causes issues with the latest stable 2.0 release. Although I think this has been fixed within master

Dotnet core sandbox issues

One of the issues currently with dotnet core is that applications seem to fail when run from within the sandbox. This includes dotnet restore or build

To exclude a particular package from the sandbox we can use the following

First we use this to create a setting called nosandbox

mkdir -p /etc/portage/env
echo 'FEATURES="-sandbox -usersandbox"' >> /etc/portage/env/nosandbox

Next we apply this to any ebuilds that need it

echo 'dev-dotnet/dotnetcore-runtime nosandbox' >> /etc/portage/package.env

I should probably mention that as of writing the current source build of dotnetcore-runtime doesn't use the dotnet restore command so it currently doesn't need this. But future versions may.

CoreSetup

Coresetup seems to be a set of scripts used to generate the runtime tar.gz However I don't think these can be used currently to generate the sdk.

I'm not sure core-setup actually builds source or just partially builds source and partially copies pre-compiled libraries in

To clone the source

git clone https://github.com/dotnet/core-setup.git
cd core-setup/
git checkout v2.0.4

To trigger the build

./init-tools.sh
./build.sh -ConfigurationGroup=Release -SkipTests

The place to look for .tar.gz files is

  • Bin/gentoo-x64.Release/packages
  • Bin/linux-x64.Release/packages

From the looks of things the tarball gz is generated by the below target

./Tools/msbuild.sh src/pkg/packaging/dir.proj /p:UsePrebuiltPortableBinariesForInstallers=true /flp:v=diag /p:TargetArchitecture=x64 /p:PortableBuild=false /p:ConfigurationGroup=Release /p:OSGroup=Linux /p:SharedFrameworkPublishDir=/root/test1/core-setup/Bin/obj/linux-x64.Release/sharedFrameworkPublish/ /target:GenerateTarBall

It's also worth checking out the commands under buildpipeline/Core-Setup-Linux-BT.json to see what's being run inside there

Source Build

Source build seems to be a set of scripts that sits on top of everything else including CoreSetup But I've not managed to get it to work fully yet.

git clone https://github.com/dotnet/source-build.git
cd source-build
git checkout dev/release/2.0
git submodule update --init --recursive

I've found you may need to edit tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks/GetHostInformation.cs So that it always returns true and sets the OS to Linux

To experiment building some stuff

./build.sh /p:RootRepo=coreclr
./build.sh /p:RootRepo=sdk

Building CoreCLR / CoreFX directly

If you want to try compiling the CoreCLR / CoreFX repo's directly

In order to build the libraries a version of the dotnet cli / sdk is needed as part of a boostrap process These typically end up un Tools/ usually build.sh will call these scripts at the beginning

./init_tools
./sync.sh

I've found that RuntimeOS needs to be specified for corefx to work right

coreclr:

./clean.sh -all
./build.sh -release -buildArch=x64 -SkipTests

corefx:

./clean.sh -all
./build.sh -release -buildArch=x64 -SkipTests -RuntimeOS=rhel.7

I've found that for some reason the build defaults to strict mode which treats warnings as errors If this happens then one way around it is to add the following to the .csproj file

<NoWarn>CS8073</NoWarn>