Usage of --shared-components with cross-builds

[Krishna-13-cyber]

Hi,
This thread is mainly for getting clarity and better understanding of feature bands for cross-compiled nature and not a bug raise. I try to run a cross build for our architecture i.e s390x , for this we need to cross compile with the x86 sdks. Ideally we are working towards the 10.0.300(release), so we have tried two approaches to build the same. We are here to talk a bit about the issues we are facing currently.

Host: x86
Target: s390x

1.Feature bands
Feature Bands concept which has been introduced here, we tried to adhere to this, we are using x86 sdks to build s390x sdks. So according to convention of feature bands we need to pass the artifacts from 10.0.1xx to 10.0.2xx and then pass the artifacts to 10.0.3xx. The catch over here is we have to cross build for our arch so we need to pass arch and rid at every stage of build, which will give us the cross compiled artifacts/outputs. We are using --sdks , in which we pass x86 sdks from releases upstream and pass prebuilt binaries from upstream with this flag--with packages. Now, for shared components which is enhanced to build higher bands from prev artifacts, we pass artifacts from the initial stage 0 build of feature band 1. These artifacts are s390x specific , which we pass with the shared component flags. Below is the command stage 1. For the Stage 1 build of 10.0.200, we pass the SDK(x86_64), packages(x86_64), and shared components(s390x) generated from the 10.0.110 source-build.

During the subsequent Stage 1 build of Feature Band 1, we consistently encounter a failure while producing the ILDasm package.The --shared-components have led to the failure as one of the nupkg, i.e runtime.linux-s390x.Microsoft.NETCore.ILDAsm.10.0.10.nupkg doesn’t seem to be in place, the nupkg doesn’t work as expected, verified it via unzip zip. This nupg comes from the artifacts generated from stage 0 build which gives s390x output.

ROOTFS_DIR=/usr/s390x-linux-gnu/ ./build.sh --source-only --clean-while-building --configuration Release --use-mono-runtime --with-system-libs "+zlib+" --source-repository "https://github.com/dotnet/dotnet" --source-version "$SOURCE_SHA" --rid linux-s390x --arch s390x --branding release --with-sdk ~/bootstrap-x86-sdk/ --with-packages ~/prev-band-packages --with-shared-components ~/shared-components/ -p:PortableBuild=true

error follows:

dotnet/repo-projects/Directory.Build.targets(275,5): error MSB4018: The "UpdateNuGetConfigPackageSourcesMappings" task failed unexpectedly. [ dotnet/repo-projects/source-build-reference-packages.proj]  dotnet/repo-projects/Directory.Build.targets(275,5): error MSB4018: System.IO.InvalidDataException->Microsoft.Build.Framework.BuildException.GenericBuildTransferredException: Invalid package:  shared-components/runtime.linux-s390x.Microsoft.NETCore.ILDAsm.10.0.10.nupkg [ dotnet/repo-projects/source-build-reference-packages.proj]  dotnet/repo-projects/Directory.Build.targets(275,5): error MSB4018: ---> System.IO.InvalidDataException->Microsoft.Build.Framework.BuildException.GenericBuildTransferredException: End of Central Directory record could not be found. [ dotnet/repo-projects/source-build-reference-packages.proj]  dotnet/repo-projects/Directory.Build.targets(275,5): error MSB4018: at System.IO.Compression.ZipArchive.ReadEndOfCentralDirectory() [ dotnet/repo-projects/source-build-reference-packages.proj]

2. Disabling Shared Components for building higher bands:
   As an alternative, we tried building with /p:DisableSharedComponentValidation=true directly for building 10.0.200(Band 2)​--with-packages (x86_64)​--with-sdk (x86_64)​. With this configuration, the build falls back to consuming upstream prebuilt SDKs and packages instead of the shared components produced by our source-build. For the 10.0.200 build, the upstream bootstrap artifacts correspond to the 10.0.103 SDK, which we also supplied as the bootstrap SDK. Using this approach allows the build to progress significantly further.It looks for specific s390x packages which it should not as we are cross-building and should rely on x86_64.
   However, when we additionally set Host=false, the build fails again. The failure is not specific to the s390x architecture; instead, it occurs in a different part of the build infrastructure, suggesting that the issue is unrelated to the s390x changes themselves and may instead be associated with the source-build or SDK bootstrap configuration.

ROOTFS_DIR=/usr/s390x-linux-gnu/ ./build.sh     --source-only     --clean-while-building     --configuration Release     --use-mono-runtime     --with-system-libs "+zlib+"     --source-repository "https://github.com/dotnet/dotnet"    --source-version "$SOURCE_SHA"     --rid linux-s390x     --arch s390x     --branding release     --with-sdk               ~/103-x86-sdk/     --with-packages          ~/10.0.103-packages/      -p:PortableBuild=true  -p:DisableSharedComponentValidation=true

error follows:

dotnet/src/sdk/src/Layout/redist/redist.csproj : error NU1100: Unable to resolve 'Microsoft.NETCore.App.Host.linux-s390x (= 10.0.3)' for 'net10.0'. PackageSourceMapping is enabled, the following source(s) were not considered: prebuilt, previously-source-built, reference-packages, source-built-diagnostics, source-built-fsharp, source-built-msbuild, source-built-nuget-client, source-built-razor, source-built-roslyn, source-built-source-build-reference-packages, source-built-sourcelink, source-built-templating, source-built-transport-arcade, source-built-transport-msbuild, source-built-transport-razor, source-built-transport-sourcelink, source-built-vstest.

FYI: For building the feature band-1 with the cross build flags works for us with the pre-built binaries fetched from upstream i.e from versions (10.0.101- 110) giving us artifacts of s390x. The build passes and binaries work on target arch. Let me know if I am doing it the right way and on correct track or deviating from the convention.

I see one more discussion with somewhat the same issue:#5520 (comment)

Thanks!

[Krishna-13-cyber]

CC: @omajid
If you can assist us here with this thread it would be helpful!

[mthalman]

So according to convention of feature bands we need to pass the artifacts from 10.0.1xx to 10.0.2xx and then pass the artifacts to 10.0.3xx.

This is true if you've building the new feature bands as they've released. But if you're starting out now and trying to build 10.0.3xx right away, you'd really want to follow the bootstrap scenario. That will let you target any feature band without having to build previous features bands (although 1xx will always be required).

For clarity 10.0.2xx feature band is EOL and 10.0.3xx will be EOL after the August release. So my recommendation is to target 10.0.400 which is shipping in next week's August release.

It's also important to match the versions configured by the branch being built. In particular, do not use the latest available 1xx artifacts with an older higher-band branch. Each branch identifies its required inputs in:

• eng/Versions.props
• eng/Version.Details.props

For example, the current runtime output of 10.0.1xx is 10.0.10 while the 10.0.200 tag is expecting 10.0.4 runtime. So if you want to follow the feature band build chain, you need to match the expected version. But again, you don't need to do that if you follow the bootstrap process; you can skip ahead to the version you want.

During the subsequent Stage 1 build of Feature Band 1, we consistently encounter a failure while producing the ILDasm package.The --shared-components have led to the failure as one of the nupkg, i.e runtime.linux-s390x.Microsoft.NETCore.ILDAsm.10.0.10.nupkg doesn’t seem to be in place, the nupkg doesn’t work as expected, verified it via unzip zip. This nupg comes from the artifacts generated from stage 0 build which gives s390x output.

So you're saying the artifacts output by the build of the 10.0.1xx branch produced this corrupted package? So this issue really isn't about feature bands at all if the output of 1xx branch is bad. Is this the only such package?

I tried this out myself using emulation in a container and could not repro it. I was able to get 1xx built and flow it to 4xx to get a 10.0.400 SDK output.

The supported feature-band workflow works, but the input versions must match the versions configured by the branch being built.

Here are the steps I took to build 1xx.

Run the container:

docker run --rm -it --platform linux/amd64 `
  -e ROOTFS_DIR=/crossrootfs/s390x `
  mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-net10.0-cross-s390x

Inside the container:

git clone --branch v10.0.110 \
  https://github.com/dotnet/dotnet.git \
  dotnet-10.0.110

cd /work/dotnet-10.0.110

./prep-source-build.sh

./build.sh \
  --source-only \
  --clean-while-building \
  --configuration Release \
  --use-mono-runtime \
  --with-system-libs "+zlib+" \
  --rid linux-s390x \
  --arch s390x \
  --branding release \
  -p:PortableBuild=true \
  -bl

[Krishna-13-cyber]

Hi Matt,
Thanks for your reply and trying for a reprod. I have tried to use the bootstrap build having known the band 1 remains mandatory (will try again if I happened to miss some versions(version mismatch).

So you're saying the artifacts output by the build of the 10.0.1xx branch produced this corrupted package? So this issue really isn't about feature bands at all if the output of 1xx branch is bad. Is this the only such package?

Uhm yes. I agree to this having no relation with feature bands.

Yes, this is the only one package from the set which happens to bug, verified it via zip/unzip to check this.

The supported feature-band workflow works, but the input versions must match the versions configured by the branch being built. Here are the steps I took to build 1xx.

Yes, for me step 1 build goes through, no prob. Except the fact that while consumption of this from the higher bands it fails on s390x.Microsoft.NETCore.ILDAsm.10.0.10.nupkg.

I am actually wanting help and interested in the flags and the steps you did for the band 10.0.400 while consuming artifacts from 10.0.1xx or 10.0.110, i.e usage of --shared-components,--with-packages, --with-sdk. Can you help me with these commands and steps as well, so that I remain on the same line.

I will try to target it for 10.0.400 the next release, by then would like try and to do it for 10.0.300.

Thanks again!