Skip to content

Fix inner build of community archs#125653

Merged
janvorli merged 2 commits intodotnet:mainfrom
am11:feature/community-arch/direct-build
Mar 20, 2026
Merged

Fix inner build of community archs#125653
janvorli merged 2 commits intodotnet:mainfrom
am11:feature/community-arch/direct-build

Conversation

@am11
Copy link
Member

@am11 am11 commented Mar 17, 2026

The full build (./build.sh) is working because it goes through MSBuild (runtime.proj) which has explicit top-level defaults setting FEATURE_DYNAMIC_CODE_COMPILED=1 for all architectures. This enables Virtual Stub Dispatch (VSD) + dynamic code generation, and riscv64/loongarch64 both have complete VSD implementations in runtime/{arch}/StubDispatch.S.

The inner build (src/coreclr/build-runtime.sh) was failing because it invoked CMake directly without the top-level context. The CMake feature logic in clrfeatures.cmake had no architecture-specific defaults, so it defaulted to FEATURE_DYNAMIC_CODE_COMPILED=0 for riscv64/loongarch64. This triggered a configuration requiring both
StubPrecodeDynamicHelpers.S and CachedInterfaceDispatchCoreCLR.S assembly stubs—neither of which were implemented for those architectures—causing undefined symbol linker errors. The CMake fix now forces FEATURE_DYNAMIC_CODE_COMPILED=1 for both architectures in `clrfeatures.cmake``, aligning the inner build with the top-level defaults.

Fixes #125642

The full build (./build.sh) is working because it goes through MSBuild
(runtime.proj) which has explicit top-level defaults setting
`FEATURE_DYNAMIC_CODE_COMPILED=1` for all architectures. This enables
Virtual Stub Dispatch (VSD) + dynamic code generation, and
riscv64/loongarch64 both have complete VSD implementations in
`runtime/{arch}/StubDispatch.S`.

The inner build (src/coreclr/build-runtime.sh) was failing because it
invoked CMake directly without the top-level context. The CMake feature
logic in clrfeatures.cmake had no architecture-specific defaults, so it
defaulted to `FEATURE_DYNAMIC_CODE_COMPILED=0` for riscv64/loongarch64.
This triggered a configuration requiring both
`StubPrecodeDynamicHelpers.S` and `CachedInterfaceDispatchCoreCLR.S`
assembly stubs—neither of which were implemented for those
architectures—causing undefined symbol linker errors. The CMake fix now
forces `FEATURE_DYNAMIC_CODE_COMPILED=1` for both architectures in
`clrfeatures.cmake``, aligning the inner build with the top-level
defaults.
@dotnet-policy-service
Copy link
Contributor

Tagging subscribers to this area: @agocke, @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

@am11 am11 marked this pull request as ready for review March 17, 2026 17:08
@am11 am11 requested a review from janvorli March 17, 2026 17:09
Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@am11
Copy link
Member Author

am11 commented Mar 20, 2026

@janvorli, thanks. Could you please merge this as well? :)

@janvorli janvorli merged commit 1253ff8 into dotnet:main Mar 20, 2026
101 of 105 checks passed
@am11 am11 deleted the feature/community-arch/direct-build branch March 20, 2026 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arch-loongarch64 arch-riscv Related to the RISC-V architecture area-Infrastructure-coreclr community-contribution Indicates that the PR has been added by a community member

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[LoongArch64] build coreclr failed when use ./src/coreclr/build-runtime.sh after PR#124168

2 participants