Failed to build tests for libs on Riscv64 #97791
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
ghost
added
the
filipnavara
added
arch-riscv
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsAfter #95980 we get next output during build of CoreCLR Build commands: After the first command the build completes successfully. Please help to fix it. cc @gbalykov
|
|
@ViktorHofer please help, what should I do? |
|
@dotnet/runtime-infrastructure can you please help? Seems to be host and prebuilt related. Possibly a component that tries to use a live built host? |
The one that I know of is src/libraries/System.Runtime.InteropServices/tests/TestAssets/NativeExports/NativeExports.csproj, at least that's what the /p:UseLocalAppHostPack=true was meant to override; not doing so resulted in ComInterfaceGenerator.Tests and LibraryImportGenerator.Tests try to use .so's for x64. But I don't see it anywhere in build log with --verbosity diag and it also fails without /p:UseLocalAppHostPack=true, so not sure if it's related to this failure. |
|
If option
|
ashaurtaev
changed the title
|
@dotnet/area-infrastructure-libraries Could you take a look, please? |
|
@ViktorHofer, this is an variant of #58109. The build flow is twisted, and we need to build it like this: # using mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-22.04-cross-riscv64
$ export ROOTFS_DIR=/crossrootfs/riscv64
# clr cross tools depend on live apphsot and host managed depends on something from sfxproj..
# so we build host.native first
$ ./build.sh host.native --cross --arch riscv64 -c Release
# now build clr+libs+tests
$ ./build.sh clr+libs --cross --arch riscv64 --runtimeConfiguration Release \
--librariesConfiguration Release --hostConfiguration Release \
--subset libs.pretest+libs.tests --testscope all -p:UseLocalAppHostPack=true
# now build packs
$ ./build.sh packs --cross --arch riscv64 -c Release
# finally the host
$ ./build.sh host --cross --arch riscv64 -c ReleaseI think linux-riscv64 at this point (while it's still a community-supported platform) provides a good opportunity to streamline the subset dependencies, because on other archs apphost gets pulled from SDK (accidentally?) in places where we don't expect. |
|
cc @dotnet/samsung |
|
Original issue with libs tests build was fixed at some point (not sure about exact commit), but before that similar problem with coreclr tests started to happen as I mentioned in #96941 (comment). Now clr, libs and libs tests build works with next commands without any issues: ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 ./build.sh --cross --clang --arch riscv64 --runtimeConfiguration Release --librariesConfiguration Release --hostConfiguration Release --subset host.native+clr.native+clr.corelib+clr.tools+clr.nativecorelib+clr.packages+clr.nativeaotlibs+clr.crossarchtools+libs.native+libs.sfx+libs.oob /p:EnableSourceLink=false
ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 ./build.sh --cross --clang --arch riscv64 --runtimeConfiguration Release --librariesConfiguration Release --hostConfiguration Release --subset libs.pretest+libs.tests --testscope all /p:EnableSourceLink=false /p:UseLocalAppHostPack=trueHowever, trying to build clr tests with next command fails: ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 BuildAsStandalone=true ./src/tests/build.sh -Release -cross -riscv64 -clang -priority1error (same as @clamp03 mentioned in #98476 (comment)): @am11 do you know what can help with this one? |
@jkoritzinsky @hoyosjs @trylek might be able to help |
|
@gbalykov, please try applying: --- a/src/tests/build.proj
+++ b/src/tests/build.proj
@@ -543,6 +543,7 @@
<Target Name="RestorePackage">
<PropertyGroup>
<_ConfigurationProperties>/p:TargetOS=$(TargetOS) /p:TargetArchitecture=$(TargetArchitecture) /p:Configuration=$(Configuration) /p:CrossBuild=$(CrossBuild)</_ConfigurationProperties>
+ <_ConfigurationProperties Condition="'$(UseLocalAppHostPack)' == 'true'">$(_ConfigurationProperties) -p:EnableAppHostPackDownload=false -p:EnableTargetingPackDownload=false -p:EnableRuntimePackDownload=false</_ConfigurationProperties>
<DotnetRestoreCommand>"$(DotNetTool)" restore $(RestoreProj) $(PackageVersionArg) /p:SetTFMForRestore=true $(_ConfigurationProperties)</DotnetRestoreCommand>
</PropertyGroup>
<Exec Command="$(DotnetRestoreCommand)"/>and add
|
|
@am11 Thanks for quick response, your fix did the trick! Now clr and libs tests can be built for riscv64 without any issues (I checked on f84d33c). Will you open PR for your patch? For reference, he's a set of commands to build coreclr, libs, coreclr tests and libs tests for riscv64: # Build coreclr + libs
ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 ./build.sh --cross --clang --arch riscv64 --runtimeConfiguration Release --librariesConfiguration Release --hostConfiguration Release --subset host.native+clr.native+clr.corelib+clr.tools+clr.nativecorelib+clr.packages+clr.nativeaotlibs+clr.crossarchtools+libs.native+libs.sfx+libs.oob /p:EnableSourceLink=false
# Build libs tests
ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 ./build.sh --cross --clang --arch riscv64 --runtimeConfiguration Release --librariesConfiguration Release --hostConfiguration Release --subset libs.pretest+libs.tests --testscope all /p:EnableSourceLink=false /p:UseLocalAppHostPack=true
# Build coreclr tests
ROOTFS_DIR=`pwd`/.tools/rootfs/riscv64 BuildAsStandalone=true ./src/tests/build.sh -Release -cross -riscv64 -clang -priority1 -p:UseLocalAppHostPack=true |
|
I wonder if this simpler command also works. Would you mind trying? |
|
Great! Yes, I will send a PR shortly. This seems like a stopgap solution. |
This also works |
|
@gbalykov side question, on riscv64 machine, looks like we need the SDK to execute tests using I downloaded the three artifacts_part.. files from today's build: https://github.com/am11/CrossRepoCITesting/releases/tag/linux-riscv64_10307028129, joined them |
Yes. However, @SzpejnaDawid recently made some progress with RISC-V SDK (and even a successful build).
We used src/tests/Common/scripts/bringup_runtest.sh during early development, it's pure bash, no SDK necessary. However, it doesn't respect exclusions in src/tests/issues.targets so the runs have false positives. For CI we rolled out our own runner scripts at least until RISC-V SDK is in good enough shape to use src/tests/run.sh. |
|
Thanks! I was thinking about doing a full source build (dotnet/dotnet) but wanted to get early results on the device with runtime build only. Running it with find -exec command atm, will grep the stats and share the logs once it’s done. |
|
@am11 as @tomeksowi mentioned you can use By the way, this issue is resolved, I think it can be closed. |
|
Yup, I added https://github.com/am11/CrossRepoCITesting/blob/2d01552673ca8f3f2fe8699076e85d441fb8c437/.github/workflows/linux-riscv64-runtime-build.yml#L31, lets see if that satisfies all the requirements for bringup script. GHA has size cap, so it requires us to be a bit mindful to not let obj dir grow too large. I used a rudimentary
I was actually investigating the TODO: integrate eng/targetingpacks.targets in src/tests/build.proj, but it's more involved than I thought. That TODO is related to this issue. I will get back to it once I get some things off my table. Meanwhile if someone else want to give it a go, here is the wip branch: main...am11:runtime:feature/cleanups/targetingpacks (will update tonight when I am on my computer; alpine build fixes were merged upstream). |
After #95980 we get next output during build of CoreCLR
Build commands:
After the first command the build completes successfully.
The error occurs in the following command:
Please help to fix it.
cc @gbalykov
The text was updated successfully, but these errors were encountered: