build-test.sh failing on ARM "Cannot create an instance of the logger."

[adamsitnik]

Steps to reproduce:

./build.sh -Release

... omitted for brevity
/home/adsitnik/coreclr
System.Private.CoreLib.dll build unsupported.
Nuget package generation unsupported.
Repo successfully built.
Product binaries are available at /home/adsitnik/coreclr/bin/Product/Linux.arm64.Release

./build-test.sh release

__DistroRid: linux-arm64
__RuntimeId: linux-arm64
Installing dotnet using Arcade...
Downloading 'https://dot.net/v1/dotnet-install.sh'
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview6-011681/dotnet-sdk-3.0.100-preview6-011681-linux-arm64.tar.gz
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview6-011681/dotnet-sdk-3.0.100-preview6-011681-linux-arm64.tar.gz
dotnet-install: Adding to current process PATH: `/home/adsitnik/coreclr/.dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.
Restoring BuildTools version 3.0.0-preview4-04022-01...
Using RID linux-arm64 for BuildTools native tools
Skipped installing build tools.
Building Tests...
__BuildOS: Linux
__BuildArch: arm64
__BuildType: Release
__TestIntermediatesDir: /home/adsitnik/coreclr/bin/tests/obj/Linux.arm64.Release
__NativeTestIntermediatesDir: /home/adsitnik/coreclr/bin/tests/obj/Linux.arm64.Release/Native
__ManagedTestIntermediatesDir: /home/adsitnik/coreclr/bin/tests/obj/Linux.arm64.Release/Managed
Creating TestBinDir: /home/adsitnik/coreclr/bin/tests/Linux.arm64.Release
Creating LogsDir: /home/adsitnik/coreclr/bin/Logs
Creating MsbuildDebugLogsDir: /home/adsitnik/coreclr/bin/Logs/MsbuildDebugLogs
Building step 'Restore product binaries (build tests)' via "/home/adsitnik/coreclr/dotnet.sh" msbuild /nologo /verbosity:minimal /clp:Summary /p:RestoreDefaultOptimizationDataPackage=false /p:PortableBuild=true /p:UsePartialNGENOptimization=false /maxcpucount /home/adsitnik/coreclr/tests/build.proj "/flp:Verbosity=normal;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.log" "/flp1:WarningsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.wrn" "/flp2:ErrorsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.err" /l:BinClashLogger,Tools/Microsoft.DotNet.Build.Tasks.dll\;LogFile=binclash.log /t:BatchRestorePackages /p:__BuildArch=arm64 /p:__BuildType=Release /p:__BuildOS=Linux
Running init-dotnet.sh
Installing dotnet using Arcade...
Running: /home/adsitnik/coreclr/.dotnet/dotnet msbuild /nologo /verbosity:minimal /clp:Summary /p:RestoreDefaultOptimizationDataPackage=false /p:PortableBuild=true /p:UsePartialNGENOptimization=false /maxcpucount /home/adsitnik/coreclr/tests/build.proj /flp:Verbosity=normal;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.log /flp1:WarningsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.wrn /flp2:ErrorsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.err /l:BinClashLogger,Tools/Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log /t:BatchRestorePackages /p:__BuildArch=arm64 /p:__BuildType=Release /p:__BuildOS=Linux
MSBUILD : error MSB1021: Cannot create an instance of the logger. The given assembly name or codebase was invalid. (0x80131047)
Switch: BinClashLogger,Tools/Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log
ERROR: An error occurred in /home/adsitnik/coreclr/.dotnet/dotnet msbuild /nologo /verbosity:minimal /clp:Summary /p:RestoreDefaultOptimizationDataPackage=false /p:PortableBuild=true /p:UsePartialNGENOptimization=false /maxcpucount /home/adsitnik/coreclr/tests/build.proj /flp:Verbosity=normal;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.log /flp1:WarningsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.wrn /flp2:ErrorsOnly;LogFile=/home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.err /l:BinClashLogger,Tools/Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log /t:BatchRestorePackages /p:__BuildArch=arm64 /p:__BuildType=Release /p:__BuildOS=Linux. Check logs under /home/adsitnik/coreclr.
Failed to build Restore product binaries (build tests). See the build logs:
    /home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.log
    /home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.wrn
    /home/adsitnik/coreclr/bin/Logs/Restore_Product.Linux.arm64.Release.err

the MSBuild logs don't exist because the logger could not be created.

[jashook]

We should remove the bin logger. Although it is worth mentioning that as of today we do not support native arm/arm64 builds. We expect the product and tests to be built on x64 with a cross toolset.

[adamsitnik]

We expect the product and tests to be built on x64 with a cross toolset.

I was not aware of it. How can I verify if my local CoreCLR change is not breaking ARM?

[RussKeldorph]

@adamsitnik https://github.com/dotnet/coreclr/blob/master/Documentation/building/cross-building.md is supposed to have the instructions. Do you just want to build the coreclr product and tests and run them?

[adamsitnik]

@RussKeldorph thanks for the link, it's very helpful!

However, I must say that it's a little bit too complicated if you just change one thing and want to check how it affects ARM without sending a PR or using more than 1 machine. It would be great to be just able to run build-test.sh on ARM machine.

[xiangzhai]

Hi @RussKeldorph

I cross build the tests for mips64r2, when run tests/runtest.sh on MIPS64 host, it stills need to download the dotnet SDK:

$ ./tests/runtest.sh 
Running on  CPU- mips64
testRootDir and other existing arguments is no longer required. If the 
default location is incorrect or does not exist, please use 
--testRootDir to explicitly override the defaults.

Build Architecture            : mips64
Build Configuration           : Debug

Skipping xunit wrapper build. If build-test was called on a different
host_os or arch the test run will most likely have failures.
python /home/loongson/zhaixiang/coreclr-mips64-dev/tests/runtest.py -arch mips64 -build_type Debug --generate_layout
host_os                  :Linux
arch                     :mips64
build_type               :Debug
coreclr_repo_location    :/home/loongson/zhaixiang/coreclr-mips64-dev
product_location         :/home/loongson/zhaixiang/coreclr-mips64-dev/bin/Product/Linux.mips64.Debug
core_root                :/home/loongson/zhaixiang/coreclr-mips64-dev/bin/tests/Linux.mips64.Debug/Tests/Core_Root
test_location            :/home/loongson/zhaixiang/coreclr-mips64-dev/bin/tests/Linux.mips64.Debug
test_native_bin_location :/home/loongson/zhaixiang/coreclr-mips64-dev/bin/obj/Linux.mips64.Debug/tests
Found COMPlus variables in the current environment

Unset COMPlus_EnableEventLog
Unset COMPlus_gcServer

TestEnv: /tmp/tmpqntkgqc1

Contents:

# Temporary test env for test run.
export COMPlus_EnableEventLog=1
export COMPlus_gcServer=0


Restoring packages...
/home/loongson/zhaixiang/coreclr-mips64-dev/dotnet.sh msbuild /nologo /verbosity:minimal /clp:Summary "/l:BinClashLogger,Tools/Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log" /p:RestoreDefaultOptimizationDataPackage=false /p:PortableBuild=true /p:UsePartialNGENOptimization=false /maxcpucount /home/loongson/zhaixiang/coreclr-mips64-dev/tests/build.proj /fileloggerparameters:"Verbosity=normal;LogFile=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/Logs/Restore_ProductLinux_mips64_Debug.log" /fileloggerparameters1:"WarningsOnly;LogFile=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/Logs/Restore_ProductLinux_mips64_Debug.wrn" /fileloggerparameters2:"ErrorsOnly;LogFile=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/Logs/Restore_ProductLinux_mips64_Debug.err" /t:BatchRestorePackages /p:__BuildType=Debug /p:__BuildArch=mips64 /p:__BuildOS=Linux

Running init-dotnet.sh
Installing dotnet using Arcade...
...
Downloading 'https://dot.net/v1/dotnet-install.sh'

But there is, of course, no dotnet SDK when porting CoreCLR and CoreFX to mips64r2 at the very begining.

Although it is able to run single testcase like this:

export LANG="zh_CN.UTF-8"
export CORE_LIBRARIES=/home/loongson/zhaixiang/corefx-3.1-Linux.mips64.Debug
export COMPlus_JitFunctionTrace=1
gdb --args ./bin/Product/Linux.mips64.Debug/corerun ./bin/tests/Linux.mips64.Debug/JIT/Methodical/doublearray/dblarray2_cs_do/dblarray2_cs_do.exe

Please teach me how to run tests for a new architecture.

Thanks,
Leslie Zhai

[jashook]

@xiangzhai you can build the native components with:

build-test.sh skipmanaged

Cross build the managed components on an x64 machine with:

build-test.sh skipnative

There is a new option which will allow you to combine the two on the target machine. I will post more tomorrow.

[jashook]

Please note that runtest.sh uses xunit under the hood. Therefore you will most likely want to use https://github.com/dotnet/coreclr/blob/master/tests/bringup_runtest.sh.

The script will most likely need work, as it was our old test harness that is no longer in use. However, it has no managed dependencies.

[jashook]

Building corefx will be required, as you will need to setup the core_root directory without restoring packages.

[jashook]

/cc @MeiChin-Tsai

[xiangzhai]

Hi @jashook

Thanks for your kind response!

Please note that runtest.sh uses xunit under the hood. Therefore you will most likely want to use https://github.com/dotnet/coreclr/blob/master/tests/bringup_runtest.sh.

The script will most likely need work, as it was our old test harness that is no longer in use. However, it has no managed dependencies.

Run tests/bringup_runtest.sh on MIPS64 host:

$ ./tests/bringup_runtest.sh --testRootDir=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/tests/Linux.mips64.Debug --coreOverlayDir=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/tests/Linux.mips64.Debug/Tests/Core_Root --testNativeBinDir=/home/loongson/zhaixiang/coreclr-mips64-dev/bin/obj/Linux.mips64.Debug/tests --coreFxBinDir=/home/loongson/zhaixiang/corefx-3.1-Linux.mips64.Debug
Running on  CPU- mips64
Skipping crossgen of FX assemblies.
Running init-tools.sh
Installing dotnet using Arcade...
...
Downloading 'https://dot.net/v1/dotnet-install.sh'
...
bash: /home/loongson/zhaixiang/coreclr-mips64-dev/.dotnet/dotnet-install.sh: No such file or directory
/home/loongson/zhaixiang/coreclr-mips64-dev/eng/common/tools.sh: line 194: Write-PipelineTelemetryError: command not found
__DistroRid: loongnix.1.0-x64
__RuntimeId: loongnix.1.0-x64
Rid to be used: ubuntu.14.04
Downloading CoreDisTools package
+ /home/loongson/zhaixiang/coreclr-mips64-dev/tests/../.dotnet/dotnet restore /home/loongson/zhaixiang/coreclr-mips64-dev/tests/src/Common/stress_dependencies/stress_dependencies.csproj --source https://dotnet.myget.org/F/dotnet-core/ --packages /home/loongson/zhaixiang/coreclr-mips64-dev/tests/../.packages
bash: /home/loongson/zhaixiang/coreclr-mips64-dev/tests/../.dotnet/dotnet: No such file or directory
Failed to restore the package
^C
*** Stopping... ***

It stills try to download the dotnet SDK... Please point out my fault!

Building corefx will be required, as you will need to setup the core_root directory without restoring packages.

I just follow the Cross compiling for native CoreFX

System.IO.Compression.Native.so
System.Native.so
System.Net.Security.Native.so
System.IO.Ports.Native.so
System.Net.Http.Native.so
System.Security.Cryptography.Native.OpenSsl.so

$ file System.IO.Compression.Native.so
System.IO.Compression.Native.so: ELF 64-bit LSB shared object, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, BuildID[sha1]=ab82144600dbfa0ac72cba3178ff1f4ff237ef1b, not stripped

And Build corefx for a new architecture

$ ls -lR *.dll | grep "^-" | wc -l
209

$ file System.Runtime.InteropServices.RuntimeInformation.dll
System.Runtime.InteropServices.RuntimeInformation.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

Thanks,
Leslie Zhai

[jashook]

@xiangzhai You should be able to safely remove the call to init-tools.sh. What branch are you working out of, I thought we removed those references?

[BruceForstall]

@xiangzhai Your issue regarding MIPS seems to be unrelated to the issue mentioned here for ARM (except both are trying to do builds on unsupported platforms). I suggest opening another issue specific to your issue.

@adamsitnik says:

It would be great to be just able to run build-test.sh on ARM machine.

Yes. If someone wants to submit PRs to make this possible, we would almost certainly take them. But it's not a priority for us currently.

[xiangzhai]

@xiangzhai You should be able to safely remove the call to init-tools.sh. What branch are you working out of, I thought we removed those references?

We are working base on, 4 months ago master branch. Our sincere thanks will goto @jkotas @AndyAyersMS @janvorli @jashook and other developers who helped us during porting to mips64r2.

We will switch to release/3.1 branch when tagged by upstream.

It is still able to run single testcase before be familiar with automated regression test.

[xiangzhai]

Hi @BruceForstall

@xiangzhai Your issue regarding MIPS seems to be unrelated to the issue mentioned here for ARM (except both are trying to do builds on unsupported platforms). I suggest opening another issue specific to your issue.

Is it able to click New issue before MIPS64 porting merged to upstream?

Thanks!
Leslie Zhai

[BruceForstall]

Is it able to click New issue before MIPS64 porting merged to upstream?

Seems ok to me. Especially if you're just asking questions.

We are working base on, 4 months ago master branch.
...
We will switch to release/3.1 branch when tagged by upstream.

Why don't you work off of master? We will never take this work into release/3.1 branch.

Is the work pushed to a public GitHub branch so we can see it, especially if questions are being asked?

[xiangzhai]

Is it able to click New issue before MIPS64 porting merged to upstream?

Seems ok to me. Especially if you're just asking questions.

Thanks a lot!

We are working base on, 4 months ago master branch.
...
We will switch to release/3.1 branch when tagged by upstream.

Why don't you work off of master? We will never take this work into release/3.1 branch.

We will maintain release/3.1 LTS branch and master.

Is the work pushed to a public GitHub branch so we can see it, especially if questions are being asked?

/cc @theaoqi

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.