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 |
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: