CoreCLR build failure with ./src/coreclr/build-runtime.sh

[gbalykov]

After #34697 clr.buildtools in build.sh subsets is required for native build, however, build-runtime.sh doesn't seem to be changed accordingly

1. ok

./build.sh --clang9 --arch x64 --configuration Release --subset clr.runtime+clr.corelib+clr.nativecorelib+clr.tools+clr.buildtools

2. error

./src/coreclr/build-runtime.sh -x64 -Release -clang9

Could not execute because the specified command or file was not found.
Possible reasons for this include:
  * You misspelled a built-in dotnet command.
  * You intended to execute a .NET Core program, but dotnet-/home/z/Dev/runtime/artifacts/bin/coreclr/Linux.x64.Release/GetModuleIndex/GetModuleIndex.dll does not exist.
  * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
src/dlls/mscordac/CMakeFiles/dac_module_index_header.dir/build.make:60: recipe for target 'src/inc/dacmoduleindex.h' failed
make[2]: *** [src/inc/dacmoduleindex.h] Error 1

cc @alpencolt

[am11]

Workaround for build-runtime.sh is:

./src/coreclr/build-runtime.sh -cmakeargs -DFEATURE_SINGLE_FILE_DIAGNOSTICS=OFF

[gbalykov]

Thanks!

[gbalykov]

Actually, shouldn't this be enabled by default for build-runtime.sh?

[am11]

Actually, shouldn't this be enabled by default for build-runtime.sh?

On supported platforms like Linux arm{64} and x{86,64} with {g,musl}libc, I think it should. We can apply a4486f7#diff-341bf51f34e3c6ab4a7abd4bc0a09880 to build-runtime.sh with condition:

    if [[ "$__IsMSBuildOnNETCoreSupported" == 1 ]]; then

in build_tools() function (like done in restore_optdata()). This way, it will abide by the existing -skipmanaged switch semantics. Maybe we can keep this issue opened to track it.

However, if someone wants to skip the download/extraction of dotnet SDK for quick compilation of native components, or working on porting runtime on non-supported platforms like Debian MIPS, uclibc, bionic-libc etc. (where dotnet(1) and compatible SDK are not available), it can be skipped explicitly (currently with -cmakeargs -DFEATURE_SINGLE_FILE_DIAGNOSTICS and if we apply the suggested patch, with -skipmanaged). Otherwise, it is a chicken-egg problem for porting work on new platforms.

@janvorli, would it be a good idea to incorporate this change in order to improve build-runtime.sh usage for scenarios beyond CI coverage?

[gbalykov]

@am11 what I meant was that DFEATURE_SINGLE_FILE_DIAGNOSTICS=OFF could be enabled by default in build-runtime.sh, keeping other semantics the same (i.e. no tools build in build-runtime.sh). Otherwise, current build-runtime.sh is broken even for supported platforms and you need to have additional knowledge on how to fix it.

[am11]

Other similar features which depend on msbuild are on by default, so by principle of least surprise, it can also be disableable with -skipmanaged, and should work on supported platform (which is currently broken and this issue is tracking).