Skip to content

Missing Microsoft.DotNet.ILCompiler package on s390x #3076

@uweigand

Description

@uweigand

When running an iterated source-build on s390x (i.e. using the output of the previous source-build as input set of package instead of the tarball), building the SDK fails due to a missing package Microsoft.DotNet.ILCompiler.

On Intel, this package is generated by the runtime repository, but on s390x this does not happen due to a check in eng/Subsets.props:

        <ProjectToBuild Condition="'$(NativeAotSupported)' == 'true' and '$(RuntimeFlavor)' != 'Mono'" Include="$(InstallerProjectRoot)\pkg\projects\nativeaot-packages.proj" Category="packs" />

Both the NativeAotSupported check and the RuntimeFlavor check fail on s390x.

Fixing this in the runtime build seems non-trivial since the actual artifacts to be packaged in that package are only created as part of the CoreCLR build, which doesn't happen on s390x.

Also, given that this package - while it itself seems to be platform-agnostic - simply adds support to the SDK to pull in various other packages needed for the NativeAOT build, and those are not available on s390x either, it seems this package shouldn't be really needed on s390x. We accept that the NativeAOT feature will not be available on the platform.

I thought this would be a simple matter of making the Microsoft.DotNet.ILCompiler line in src/Layout/redist/targets/BundledSdks.targets in the SDK repo conditional on the platform. But it turns out this isn't easily possible as the SDK repo build as part of the source-build process doesn't appear to even be aware which platform is being targeted. None of the Architecture, TargetRid or Platform properties (or any other property I could identify) are set to indicate a s390x target architecture.

We could disable the line for building with source-build generally, but I understand this is undesirable, as there is supposed to be NativeAOT support on Intel (even though the compiler packages aren't build with source-build, they would be pulled in from nuget at runtime if the SDK support is available).

@crummel any suggestions on how to best address this problem?

FYI - @tmds @omajid @janani66

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-buildImprovements in source-build's own build process

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions