Runtime: ARM 32 位进展

创建于 2016-03-30  ·  123评论  ·  资料来源: dotnet/runtime

我正在打开一个问题来跟踪 ARM 32 位在回归测试方面的进展。

目前,我在 NVidia Jetson TK1 上运行的 Ubuntu 14.04 上得到以下结果。 不幸的是,这不是您从干净结帐中获得的结果,唯一的区别是它包含对问题 dotnet/runtime#5422 (PR dotnet/coreclr#3879) 的修复,但总体而言,它应该为监控我们的进度提供一个良好的基础:

=======================
     Test Results
=======================
# Tests Discovered : 6018
# Passed           : 4313
# Failed           : 1361
# Skipped          : 344
=======================

我附上了 XML 结果:
coreclrtests.zip

arch-arm32

最有用的评论

最后...
这是使用硬 FP ABI 的 Raspberry Pi 2 的最新结果。 :)
445405d84034564a6433074e0f920f74105ba499

=======================
     Test Results 
=======================
# Tests Discovered : 11399
# Passed           : 11035
# Failed           : 0
# Skipped          : 364
=======================
constructing /home/sjlee/unit_test/dumplings.txt
270 minutes and 5 seconds taken to run CoreCLR tests.

testsUnsupportedOnARM32.txt设置如下

JIT/Directed/tailcall/tailcall/tailcall.sh
JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh
JIT/Methodical/tailcall_v4/hijacking/hijacking.sh
JIT/Methodical/tailcall_v4/smallFrame/smallFrame.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof32/_il_dbgsizeof32.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof64/_il_dbgsizeof64.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof/_il_dbgsizeof.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof32/_il_relsizeof32.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof64/_il_relsizeof64.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof/_il_relsizeof.sh
JIT/Regression/JitBlue/devdiv_902271/DevDiv_902271/DevDiv_902271.sh

所有123条评论

不幸的是,这不是您从干净结帐中获得的结果,

即使您可以获得1,361 Failed结果,但这个结果对我来说很有意义。 实际上,我们已经遇到了很多来自CoreCLR的“NYI”功能。:(这意味着我们必须做很多事情来稳定CoreCLR。

目前我在 NVidia Jetson TK1 上运行的 Ubuntu 14.04 上得到以下结果

顺便说一句,您是否还专注于没有 Ubuntu/ARM64 位的 Ubuntu/ARM32 位?
http://elinux.org/Jetson_TK1

  • CPU:NVIDIA "4-Plus-1" 2.32GHz ARM 四核 Cortex-A15 CPU,带有 Cortex-A15 省电影子内核
  • GPU:具有 192 个 SM3.2 CUDA 内核的 NVIDIA Kepler “GK20a” GPU(最高 326 GFLOPS)
  • 内存:~ 8GiB DDR3

\CC: @myungjoo ,@lemmaa
他们还对 CoreCLR 的回归测试感兴趣。

@leemgs我不确定没有 Ubuntu/ARM32bit 部分的 Ubuntu/ARM32bit 是什么意思?

@manu-silicon 对不起,错字,我已经修改了。

@leemgs我的主板是 32 位版本,所以它只是 Ubuntu/ARM32 位。

https://en.wikipedia.org/wiki/Tegra#Tegra_K1

修复 PR dotnet/coreclr#3981 结果是:

=======================
     Test Results
=======================
# Tests Discovered : 6019
# Passed           : 4793
# Failed           : 882
# Skipped          : 344
=======================

coreclrtests.zip

@manu-silicon 我正在尝试按照本指南https://github.com/dotnet/coreclr/blob/master/Documentation/building/unix-test-instructions.md做同样的事情(在 ARM 环境上运行 coreclr 测试)

我想问一下您是如何为 ARM 环境构建测试二进制文件的(使用 buildtest.cmd)。 您是否进行了一些本地更改(仅构建 C# 代码并忽略 CMake 构建)还是有其他方法可以做到这一点?

@prajwal-aithal 我已按照说明在 Windows 上构建测试并在 Linux ARM 上复制测试文件夹。 我在 ARM 上构建了 CoreFX 的本机代码(只是本机代码,其余的不会构建)。 我在 Linux x64 上构建了 CoreFX 并复制了程序集。 我在 Linux x64 上构建了 mscorlib 并将其复制过来。

一旦我正确设置了所有路径,我就启动了命令来运行测试。

@manu-silicon 哦,好的。 那我试试这个。 谢谢 :)

今天禁用 FEATURE_STUBS_AS_IL 的结果:

=======================
     Test Results
=======================
# Tests Discovered : 6019
# Passed           : 4836
# Failed           : 839
# Skipped          : 344
=======================

coreclrtests.zip

目标:树莓派2
CoreClr 提交 ID:ff26d6801b3ce0dec5918a5ad0d3ab90f9656e28(4 月 9 日左右)

=======================
     Test Results
=======================
# Tests Discovered : 7422
# Passed           : 6074
# Failed           : 1017
# Skipped          : 331
=======================

我很好奇为什么我的测试发现计数与其他人不同。
CoreClr_UnitTest_Results_160412_01.zip

@jyoungyun下次请附上结果 XML 文件。

@jyoungyun测试数量的差异与我如何首先在 Windows 上构建测试然后将它们复制到 Linux ARM 设备有关。 正如@myungjoo所说,拥有 XML 文件将使我们能够比较并查看差异是什么。

@manu-silicon 我附加了 xml 文件。 谢谢你。

目标:树莓派2
Coreclr 提交 ID:31fada1 + dotnet/coreclr#4460 + dotnet/coreclr#4503

==========================
      Test Results
==========================
# Tests Discovered : 7421
# Passed           : 6547
# Failed           : 543
# Skipped          : 331
==========================

CoreClr_UnitTest_Results_160427.zip

哇,所以这两个修复清除了大约一半的失败测试? 好的!

@masonwheeler是的! dotnet/coreclr#4460 补丁减少了一半的失败测试。 :)

目标:树莓派2
Coreclr 提交 ID:18268be + dotnet/coreclr#4503 + dotnet/coreclr#4581

==========================                                                      
      Test Results                                                              
==========================                                                      
# Tests Discovered : 6018                                                       
# Passed           : 5295                                                       
# Failed           : 395                                                        
# Skipped          : 328                                                        
==========================  

我发现我的测试发现计数与其他人不同的原因。
我的测试目录结构错误。 现在其他人也一样。 :)

CoreClr_UnitTest_Results_160428.zip

@jyoungyun ,太棒了。 :) 顺便说一句, https ://github.com/dotnet/coreclr/commit/18268beae931cbd4d110959ea53d785b193eceb1 与减少故障的数量有关吗? 似乎与 Linux/ARM 的单元测试的失败数无关。

@jyoungyun如果可能的话,很高兴知道每个错误修复解决了多少测试。

@jyoungyun出于好奇,您运行所有测试需要多长时间。 对使用 Jetson TK1 的我来说,大约需要半天时间。

@manu-silicon 我们将很快推出加速 ARM corerun 执行的补丁。 @leemgs正在为此准备 PR(发布构建错误修复)

作为参考,@manu-silicon 分享了他用于获取单元测试结果的硬件规范。 这是他的开发板的详细内容。

@leemgs哦,数字(18268be)表示基本提交。 有人想重现结果,即基本提交信息。 会有帮助的。 我认为减少失败测试用例更多地与 dotnet/coreclr#4460 补丁有关。
@manu-silicon 在 Raspberry pi2 上运行 unix 测试需要很长时间。 就我而言,大约 12 小时是通常所需的时间。 但是当我使用发布模式的二进制文件时,只需要 4 个小时! 我希望@leemgs补丁能很快准备好。

在 lastet 提交(92d709193a8ee3d8da3519811912ec0f7a552993)中,我得到了更好的结果。 我正在调查几个故障,其中许多故障已在最新的 master 分支中修复。
任何人都可以再次运行整个测试吗?

@hqueue我可以在星期五做。

试图在周五运行测试套件,但它卡在了我必须手动终止的 2 个测试上:

FAILED   - JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b425314/b425314/b425314.sh
               BEGIN EXECUTION
               /home/ubuntu/local/Microsoft/tests/Tests/coreoverlay/corerun b425314.exe
               ./b425314.sh: line 62: 32428 Killed                  $_DebuggerFullPath "$CORE_ROOT/corerun" b425314.exe $CLRTestExecutionArguments $Host_Args
               Expected: 100
               Actual: 137
               END EXECUTION - FAILED

FAILED   - JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b426654/b426654/b426654.sh
               BEGIN EXECUTION
               /home/ubuntu/local/Microsoft/tests/Tests/coreoverlay/corerun b426654.exe
               ./b426654.sh: line 62: 10285 Killed                  $_DebuggerFullPath "$CORE_ROOT/corerun" b426654.exe $CLRTestExecutionArguments $Host_Args
               Expected: 100
               Actual: 137
               END EXECUTION - FAILED

跑步终于完成了。 Jetson TK1 提交的结果 3ddd9c43821bf617621f87d8d1519229e7d3b789

=======================
     Test Results
=======================
# Tests Discovered : 6019
# Passed           : 5478
# Failed           : 234
# Skipped          : 307
=======================

coreclrtests_2016_05_06.zip

最新单元测试结果!

目标:树莓派2
Coreclr 提交 ID:6b92cff6

==========================
      Test Results
==========================
# Tests Discovered : 6530
# Passed           : 5981
# Failed           : 215
# Skipped          : 334
==========================

CoreClr_UnitTest_Results_160510.zip

@manu-silicon 当我运行 unix 测试时,一些 tc 需要很长时间。 并且阻塞的tc被改变了。 你见过同样的案例吗?

请注意,我们有大约 120 次失败,因为回归有望通过 dotnet/coreclr#4888 轻松修复。 我们可能很快就会看到不到 100 个失败。

@jyoungyun我不确定你所说的“tc is changed”是什么意思。 但正如我在发布结果之前所说的那样,我有 2 个测试挂起,阻止了其余测试用例的运行。 我不得不手动杀死它们才能完成。

@manu-silicon 哦,我的意思是当我尝试运行 unixtest 时,我卡在了不同的 tcs 上。 有时 b425314 挂起,而其他时候 tc 没有挂起,而另一个 tc 卡住了。 所以我每次都不得不手动杀死它们。 我徘徊为什么每次挂tc都不一样,想知道你见过同样的情况。 如果卡住的 tc 始终相同,我们可以修改 tests/testsFailingOutsideWindows.txt 以在不手动杀死的情况下完成,即使这是一种临时方式。

太奇妙了。 失败的tc终于是两位数了! :+1:

目标:树莓派2
Coreclr 提交 ID:9eba7d3

==========================
      Test Results
==========================
# Tests Discovered : 6530
# Passed           : 6137
# Failed           : 98
# Skipped          : 295
==========================

哇,看到我去年开始的事情能走到这一步真是太棒了。 抱歉,我不能再进一步了,但 ARM 似乎很快就会成为 .NET Core 的可行目标。

看来我们今天甚至会看到它在 40 左右。 (或少于 40 个!)。

今天的结果!

目标:树莓派2
Coreclr 通讯 ID:1c2d8a6
TC 提交 ID:171f7133287ebbee24d6a7f193b13a9f959e9297

==========================
      Test Results
==========================
# Tests Discovered : 6966
# Passed           : 6626
# Failed           : 49
# Skipped          : 291
==========================

很高兴在这里看到这样的进步!

很不错! 大进步!
一旦所有这些 Pri0 测试通过,您是否有下一个目标? 是 Pri1 测试(大约 3000 个额外测试)吗?

对所有人,

这是另一个笔记。 我总结了在三星 ARM ChromeBook 上使用 Release-build 模式的 coreCLR 的单元测试结果。 请注意,以下结果是由Release-build模式执行的。

在执行以下 3 个步骤之前

=======================
     Test Results
=======================
# CoreCLR Binary Folder: /unit-test/bin.coreclr.20160517/Product/Linux.arm.Release
# Tests Discovered : 6966
# Passed           : 6282
# Failed           : 420 ★
# Skipped          : 264
=======================
* Priority 0 (default)
* Target: Samsung ARM Chromebook
* Run Time: 89m32.452s (13h in debug-build)
* CoreCLR Commit No: May-15-2016

coreclrtests.release.failur-420.20160515.zip

然后,执行以下 3 个步骤后,我们可以得到 67 次失败。 在这种情况下,我们将优先级设置为 666(而不是优先级 0)以增加测试用例。
1)重新同步发布二进制文件中的所有组件(没有调试构建模式)
2) 添加所有托管文件(Linux、Unix、AnyOS)
3) UNW_ARM_UNWIND_METHOD 返回:默认
(来源:https://wiki.linaro.org/KenWerner/Sandbox/libunwind#overhead_of_the_ARM_specific_unwind-tables)

完成以上3个步骤后

=======================
     Test Results
=======================
# CoreCLR Binary Folder: /unit-test/bin.coreclr.20160517/Product/Linux.arm.Release
# Tests Discovered : 9870
# Passed           : 9458
# Failed           : 67  ★
# Skipped          : 345
=======================
* Priority 666
* Target: Samsung ARM Chromebook
* Run Time: 128m55.349s (15h in debug-build)
* CoreCLR Commit No: May-15-2016

coreclrtests.chromebook.release.failure-67.20160518.zip

前两天,结果。
我运行单元测试,包括测试优先级 0 和 1,但之前的失败计数几乎相同。 :)

目标:树莓派2
Coreclr Commt id : e78338e (日期: Tue May 17 17:19:37 2016 -0700)
tc commit id : 4941764c (日期: Mon May 16 22:46:36 2016 -0700)

==========================
      Test Results (Debug)
==========================
# Tests Discovered : 9870
# Passed           : 9423
# Failed           : 102
# Skipped          : 345
==========================

@leemgs

2) 添加所有托管文件(Linux、Unix、AnyOS)

你把那些托管的东西放在哪里了?
您是如何使用这些文件运行测试的?

你把那些托管的东西放在哪里了?

@mkborg ,我通过在 Ubuntu 14.04 X64 上构建 coreFX 源获得了托管的东西。

您是如何使用这些文件运行测试的?

  • 之前:--coreFxBinDir="../corefx.bin/AnyOS.AnyCPU.Release"
  • 之后:--coreFxBinDir="../corefx.bin/Linux.AnyCPU.Release;../corefx.bin/Unix.AnyCPU.Release;\
    ../corefx.bin/AnyOS.AnyCPU.Release"

我会试试看。

) UNW_ARM_UNWIND_METHOD 返回:默认

我会试试看。

@mkborg ,如果可以,我建议您也尝试检查不同的 ARM 展开方法(例如,UNW_ARM_UNWIND_METHOD=1|2|...|255)

dotnet/coreclr#5087 经测试可解决 5 个失败的 ARM/Linux 测试用例 (PR0)

只是想感谢大家为这个问题贡献了他们的时间<3

嘿,我刚刚用 TK1 在我的 ARM Chromebook 上设置了 CoreCLR。 还需要文档中的补丁吗?

@Toxantron ,您可以通过参考 coreclr 的文档在自己的 arm chromebook 上轻松设置 corclr/corefx 环境。 根据我的经验,我建议您将可用的 USB 记忆棒用于基于 ubuntu/arm 14.04 的 dotnet 核心。

这是最近在 Raspberry Pi2 上的单元测试结果。
CoreCLR 提交为 38a89155cb2c53a9603d2234731525abdd974014,TC 提交为 38a89155cb2c53a9603d2234731525abdd974014,优先级为 666。
我也添加了 PAL 测试结果。

==========================
      Test Results
==========================
# CoreCLR Bin Dir  : /home/dotnet/tmp/coreclr/bin/Product/Linux.arm.Debug
# Tests Discovered : 9853
# Passed           : 9448
# Failed           : 53
# Skipped          : 352
==========================
1493 minutes and 27 seconds taken to run CoreCLR tests.

==========================
PAL Test Results:
  Passed: 807
  Failed: 1
==========================

我们观察到不同 ARM 设备中的故障减少了大约 20 次。 我们还需要看看是什么造成了这种差异。

我最近的测试有很多失败:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : /coreclr-testing/20160706/odroid-2.arm-softfp/odroid-2.coreclr_46d3809.corefx_860d28c.arm-softfp/CORECLR_NATIVE/coreclr/bin/Product/Linux.arm-softfp.Debug
# Tests Discovered : 9870
# Passed           : 9124
# Failed           : 394
# Skipped          : 352
=======================

是我的本地问题还是实际回归?

@jyoungyun你目前的测试结果是什么?

@mkborg我的结果和你几乎一样。 Raspberry pi 未能通过 400 多项测试。 dotnet/coreclr#6051 这是相关问题。

我的结果和你几乎一样。 Raspberry pi 未能通过 400 多项测试。 dotnet/coreclr#6051 这是相关问题。

添加@chunseoklee ,您能否在@jyoungyun的评论和@mkborkg的测试结果之间同步类似的问题(例如Failed 394)?

/抄送: @parjong

上面提到的回归由 597e160 commit(PR dotnet/coreclr#6088 ) 处理,它改变了异常处理程序的行为。
此 PR dotnet/coreclr#6117 通过 597e160 提交解决了单元测试回归问题。

这是我在 Raspberry Pi2 中的结果。
提交号 c9287008
我希望当@chunseoklee的补丁被合并时,很多问题都会过去。

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : /home/dotnet/tmp/coreclr/bin/Product/Linux.arm.Debug
# Tests Discovered : 9870
# Passed           : 8935
# Failed           : 583
# Skipped          : 352
=======================

在我的网站上,带有 PR dotnet/coreclr#6117 的 CoreCLR (c29547fc155) 显示以下结果(我使用了 Release CoreCLR / Release TC):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 9870
# Passed           : 9497
# Failed           : 36
# Skipped          : 337
=======================

@parjong感谢您分享单元测试结果。 BTW,你能保留# CoreCLR Bin Dir的内容来了解​​实验设备的评估环境吗?

@leemgs不幸的是,CoreCLR Bin Dir 行不适用于runtest.sh--coerOverlayDir (我用于测试)。 相反,我通常将信息保存在单独的位置。

对于上述结果,我使用 CoreCLR 和 -O1 发布模式 c29547fc155 和 PR dotnet/coreclr#6117,以及 TC 和 387d9fc0a 的发布模式。

在失败的测试中,目前看来至少有九个测试可以被认为是 ARM 32 位的误报失败。

根据问题 dotnet/coreclr#6248,6测试在 ARM 32 位上失败,因为 unix 测试是为 64 位架构(x64)构建的,其中native int是 64 位。
我运行了六个为 32 位(即 x86)构建的测试,所有六个测试都在 arm-softfp/Linux 上通过。
然而,我们现在似乎无法为 x86 构建全套 unix 测试,因为tests/buildtest.cmd说它只支持 x64。 (有一个讨论在 Linux 中构建 unix 测试的问题(问题 dotnet/coreclr#4437),但不是关于 32/64 位)

此外,由于缺少 ARM 32 位的 FEATURE_FASTTAILCALL,三个测试失败,如问题 dotnet/coreclr#6217 中所述。

此外,由于缺乏对 ARM 32 位的 R2R 支持,也有四个测试失败,如问题 dotnet/coreclr#6231 中所述。

欢迎来到发布构建世界!!! 我的意思是,我们将通过启用 Release + -O3(默认)来迎接更多的技术挑战。 应用 PR https://github.com/dotnet/coreclr/pull/6379 后,单元测试失败次数为 47(如调试构建模式)。

=======================
     Test Results (Release + O3)
=======================
# CoreCLR Bin Dir  : /unit-test/bin.coreclr.release.20160627.1.O3.attribute.1.refacto1/Product/Linux.arm.Release
# Tests Discovered : 9873
# Passed           : 9465
# Failed           : 47 (commit: 20160627-52570683, OOM: 2,  manual kill commands: 0 ) <=== N O W ! ! !
# Skipped          : 361
=======================
117 minutes and 42 seconds taken to run CoreCLR tests.

real    119m15.377s
user    145m21.515s
sys 17m23.065s

供参考。 我在 Linux/ARM 板上用最新的提交号评估了 CoreCLR 的单元测试。

  • 提交编号:c358f77a1ddcf31475450c40af64ad115259e622(2016 年 7 月 25 日)+ PR dotnet/coreclr#6379(PR 将很快合并)
  • 构建模式:发布构建 + O3(默认)
  • 在三星 ARM ChromeBook 上
  • 操作系统:Ubuntu/ARM 14.04 32bit (hard-fp)
  • 应用 PR 后的单元测试结果:(OOM:2,手动终止命令:1)
=======================
     Test Results
=======================
# CoreCLR Bin Dir  : /unit-test/bin.coreclr.release.O3.054d133a.20160725.1/Product/Linux.arm.Release
# Tests Discovered : 9873
# Passed           : 9484
# Failed           : 28
# Skipped          : 361
=======================
164 minutes and 14 seconds taken to run CoreCLR tests.

real    165m24.788s
user    153m41.410s
sys 56m11.885s
root<strong i="12">@target</strong>:/unit-test/coreclr.git/tests# 

@leemgs您是否尝试使用emulator rootfs 为 ARM soft FP构建 CoreCLR? 我收到以下错误构建与您的修补clang3.6

../../coreclr/hosts/unixcoreruncommon/libunixcoreruncommon.a(coreruncommon.cpp.o): In function `std::string::_M_check(unsigned int, char const*) const':
/CROSS-ROOTFS/emulator/usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9.2/include/c++/bits/basic_string.h:324: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
/CROSS-ROOTFS/emulator/usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9.2/include/c++/bits/basic_string.h:324: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
/CROSS-ROOTFS/emulator/usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9.2/include/c++/bits/basic_string.h:324: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'

但是,如果我使用未经修改的上游clang-3.8clang-3.5 ,则构建成功。

@leemgs您是否尝试使用模拟器rootfs为ARM soft FP构建CoreCLR?
我收到以下错误构建与您修补的 clang3.6:

没问题。 我还可以使用模拟器 rootfs 为 Linux/ARM softFP 构建 CoreCLR,如下所示:

 . . . . . . . UPPER OMISSION . . . . . . .
  NuGet Config files used:
      /work/dotnet/coreclr.git/src/NuGet.Config
      /home/invain/.nuget/NuGet/NuGet.Config

  Feeds used:
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
Generating nuget packages for Linux
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
  Skipping nuspec generation for this platform.
Repo successfully built.
Product binaries are available at /work/dotnet/coreclr.git/bin/Product/Linux.arm-softfp.Release
1826.83user 88.72system 5:18.30elapsed 601%CPU (0avgtext+0avgdata 466172maxresident)k
977800inputs+9311672outputs (652major+39210140minor)pagefaults 0swaps
invain<strong i="10">@db400</strong>:/work/dotnet/coreclr.git$ 
invain<strong i="11">@db400</strong>:/work/dotnet/coreclr.git$ 
invain<strong i="12">@db400</strong>:/work/dotnet/coreclr.git$ 
invain<strong i="13">@db400</strong>:/work/dotnet/coreclr.git$ dpkg -l | grep clang
ii  clang-3.6                                                   1:3.6-2ubuntu1~trusty1ubuntu3                       amd64        C, C++ and Objective-C compiler (LLVM based)
ii  libclang-common-3.6-dev                                     1:3.6-2ubuntu1~trusty1ubuntu3                       amd64        clang library - Common development package
ii  libclang1-3.6:amd64                                         1:3.6-2ubuntu1~trusty1ubuntu3                       amd64        C interface to the clang library
invain<strong i="14">@db400</strong>:/work/dotnet/coreclr.git$ 

\CC:@ sjsinju ,@prajwal-aithal

/CROSS-ROOTFS/emulator/usr/lib/gcc/...gnueabi/4.9.2/include/c++/bits/basic_string.h:324: 未定义引用`std::__throw_out_of_range_fmt(char const*, ... )'

@mkborg ,如果你还是遇到同样的问题,我建议你参考我之前分享的Issue dotnet/coreclr#5600。

我总结了发布构建模式下不同优化级别(例如-O1、-O2、-O3 {默认}、-Oz和-Ofast)中主要文件的文件大小比较如下。 此外,您可以在“ 6. Linux/ARM: Release Build + Mono 4.4.1: Stripped , (Nightly 4.4.1.0/4747417 Wed Jun 22 11:38:12 UTC 2016) ”处查看 Mono 4.4.1(最新版本)的文件大小

1. Linux/ARM: Release Build + O1: stripped , commit: 561b64d2c210b4d999de7f1ac55756704eaba784 (Jul-26-2016)

-rwxr-xr-x 1 leemgs leemgs 22,608 Jul 29 07:30 corerun
-rwxr-xr-x 1 leemgs leemgs 3,698,544 Jul 29 07:29 libcoreclr.so
-rwxr-xr-x 1 leemgs leemgs 1,254,968 Jul 29 07:29 libclrjit.so
-rwxr--r-- 1 leemgs leemgs 29,696 Jul 29 00:55 ./mscorlib.dll
-rwxr--r-- 1 leemgs leemgs 2,211,840 Jul 29 00:54 ./System.Private.CoreLib.dll
总计:7,217,656 字节

2. Linux/ARM:发布构建 + O2:剥离,提交:561b64d2c210b4d999de7f1ac55756704eaba784(2016 年 7 月 26 日)

-rwxr-xr-x 1 leemgs leemgs 18,496 Jul 27 07:49 corerun
-rwxr-xr-x 1 leemgs leemgs 4,275,520 Jul 27 07:49 ./libcoreclr.so
-rwxr-xr-x 1 leemgs leemgs 1,447,324 Jul 27 07:49 ./libclrjit.so
-rwxr--r-- 1 leemgs leemgs 29,696 Jul 27 00:55 ./mscorlib.dll
-rwxr--r-- 1 leemgs leemgs 2,211,840 Jul 27 00:54 ./System.Private.CoreLib.dll
总计:7,982,876 字节

3. Linux/ARM: Release Build + O3(默认): stripped , commit: 561b64d2c210b4d999de7f1ac55756704eaba784 (Jul-26-2016)

-rwxr-xr-x 1 leemgs leemgs 18,472 Jul 27 16:14 corerun
-rwxr-xr-x 1 leemgs leemgs 1,512,828 Jul 27 18:33 libclrjit.so
-rwxr-xr-x 1 leemgs leemgs 4,525,328 Jul 27 18:33 libcoreclr.so
-rwxr--r-- 1 leemgs leemgs 29,696 Jul 27 00:55 ./mscorlib.dll
-rwxr--r-- 1 leemgs leemgs 2,211,840 Jul 27 00:54 ./System.Private.CoreLib.dll
总计:8,298,164 字节

4. Linux/ARM: Release Build + Ofast: stripped, commit: 561b64d2c210b4d999de7f1ac55756704eaba784 (Jul-26-2016)

-rwxr-xr-x 1 leemgs leemgs 18,496 Jul 26 05:00 ./corerun
-rwxr-xr-x 1 leemgs leemgs 1,512,844 Jul 26 04:59 ./libclrjit.so
-rwxr-xr-x 1 leemgs leemgs 4,525,360 Jul 26 04:59 ./libcoreclr.so
-rwxr--r-- 1 leemgs leemgs 29,696 Jul 26 00:49 ./mscorlib.dll
-rwxr--r-- 1 leemgs leemgs 2,211,840 Jul 26 00:48 ./System.Private.CoreLib.dll
总计:8,298,236 字节

5. Linux/ARM: Release Build + Oz: stripped, commit: 561b64d2c210b4d999de7f1ac55756704eaba784 (Jul-26-2016)

-rwxr-xr-x 1 leemgs leemgs 14,400 Jul 29 05:02 ./corerun
-rwxr-xr-x 1 leemgs leemgs 1,181,160 Jul 29 04:40 ./libclrjit.so
-rwxr-xr-x 1 leemgs leemgs 3,407,200 Jul 29 04:40 ./libcoreclr.so
-rwxr--r-- 1 leemgs leemgs 29,696 Jul 29 00:49 ./mscorlib.dll
-rwxr--r-- 1 leemgs leemgs 2,211,840 Jul 29 00:48 ./System.Private.CoreLib.dll
总计:6,844,296 字节

6. Linux/ARM: Release Build + Mono 4.4.1: Stripped, (每晚 4.4.1.0/4747417 Wed Jun 22 11:38:12 UTC 2016)

lrwxrwxrwx 1 leemgs leemgs 9 Jun 22 12:00 /usr/bin/mono -> mono-sgen
-rwxr-xr-x 1 leemgs leemgs 2,252,904 Jun 22 12:00 /usr/bin/mono-sgen(单声道运行时 [SGen])
-rw-r--r-- 1 leemgs leemgs 2,403,964 Jun 22 12:00 /usr/lib/libmonosgen-2.0.so.1.0.0(Mono JIT 库 [SGen GC])
-rw-r--r-- 1 leemgs leemgs 3,753,984 Jun 22 11:22 /usr/lib/mono/4.5/mscorlib.dll
总计:8,410,861 字节

并且,下面的实验结果是 Raspberry Pi2 (Ubuntu/ARM 14.04) 上单元测试失败的次数。 PR https://github.com/dotnet/coreclr/pull/6548将很快合并为-Oz(用于大小)和Ofast(用于速度)的指令。

[发布版本中的 CoreCLR 单元测试:-O3 VS。 -奥兹VS。 -Ofast]

  • Release Build + O3:release build 模式下的默认优化级别
=======================
     Test Results (Release + O3 )
=======================
# CoreCLR Bin Dir  : /unit-test/bin.coreclr.release.O3.054d133a.20160725.1/Product/Linux.arm.Release
# Tests Discovered : 9873
# Passed           : 9465
# Failed           : 47  
# Skipped          : 361
=======================
118 minutes and 33 seconds taken to run CoreCLR tests.

real  119m39.397s
user  147m13.410s
sys 17m9.900s
root<strong i="10">@target</strong>:/unit-test/coreclr.git/tests# 
  • Release Build + Oz:尺寸
=======================
     Test Results  (Release + Oz )
=======================
# CoreCLR Bin Dir  : /unit-test/bin.coreclr.release.Oz.054d133a.20160725.1/Product/Linux.arm.Release
# Tests Discovered : 9873
# Passed           : 9483
# Failed           : 29
# Skipped          : 361
=======================
128 minutes and 9 seconds taken to run CoreCLR tests.

real    129m42.436s
user    163m18.785s
sys 15m50.260s
root<strong i="15">@target</strong>:/unit-test/coreclr.git/tests# 
  • Release Build + Ofast:为了速度
=======================
     Test Results  (Release + Ofast )
=======================
# CoreCLR Bin Dir  : /unit-test/bin.coreclr.release.Ofast.054d133a.20160725.1/Product/Linux.arm.Release
# Tests Discovered : 9873
# Passed           : 9477
# Failed           : 35
# Skipped          : 361
=======================
144 minutes and 52 seconds taken to run CoreCLR tests.

real    146m26.534s
user    150m25.765s
sys 40m38.195s
root<strong i="20">@target</strong>:/unit-test/coreclr.git/tests# 
--------------------------------------------------

+1 用于手臂设备

@leemgs你知道 CoreCLR 单元测试通过率的现状是什么吗?

@janvorli我无意中听到它在这些天在隔间的 10000 多个案例中的 1 到 15 之间波动 :)
而且,似乎除了最后几个之外,它们都是由于不正确的测试用例或测试用例的不正确使用造成的。

@jyoungyun你能发布一个最近正确的结果吗?

这是使用硬 FP ABI 的 Raspberry Pi 3 的最新结果

=======================
     Test Results
=======================
Elapsed:    353 min, 54 sec
Discovered: 11386
Passed:     11010
Failed:     14
Skipped:    362

Failed test:
  CoreMangLib.cti.system.datetime.DateTimeParse1.DateTimeParse1
  Exceptions.ForeignThread.ForeignThreadExceptions.ForeignThreadExceptions
  JIT.jit64.opt.cse.HugeArray.HugeArray
  JIT.jit64.opt.cse.hugeexpr1.hugeexpr1
  JIT.jit64.opt.cse.HugeField1.HugeField1
  JIT.jit64.opt.cse.HugeField2.HugeField2
  JIT.jit64.opt.cse.hugeSimpleExpr1.hugeSimpleExpr1
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof32._il_dbgsizeof32
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof64._il_dbgsizeof64
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof._il_dbgsizeof
  JIT.Methodical.xxobj.sizeof._il_relsizeof32._il_relsizeof32
  JIT.Methodical.xxobj.sizeof._il_relsizeof64._il_relsizeof64
  JIT.Methodical.xxobj.sizeof._il_relsizeof._il_relsizeof
  JIT.superpmi.superpmicollect.superpmicollect

这是另一个使用 Soft FP ABI 的 ARM 设备的最新结果:

=======================
     Test Results
=======================
Elapsed:    179 min, 52 sec
Discovered: 11386
Passed:     11012
Failed:     12
Skipped:    362

Failed test:
  CoreMangLib.cti.system.datetime.DateTimeParse1.DateTimeParse1
  GC.Regressions.v2.0-rtm.494226.494226.494226
  JIT.jit64.opt.cse.hugeexpr1.hugeexpr1
  JIT.jit64.opt.cse.HugeField1.HugeField1
  JIT.jit64.opt.cse.HugeField2.HugeField2
  JIT.jit64.opt.cse.hugeSimpleExpr1.hugeSimpleExpr1
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof32._il_dbgsizeof32
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof64._il_dbgsizeof64
  JIT.Methodical.xxobj.sizeof._il_dbgsizeof._il_dbgsizeof
  JIT.Methodical.xxobj.sizeof._il_relsizeof32._il_relsizeof32
  JIT.Methodical.xxobj.sizeof._il_relsizeof64._il_relsizeof64
  JIT.Methodical.xxobj.sizeof._il_relsizeof._il_relsizeof

这是我对后一个结果的观察。

  • dotnet/coreclr#6680 与 JIT.Methodical.xxobj.sizeof._il 下的所有故障有关。
  • 缺少物理内存(因为设备只有 1G 内存)似乎导致了除 DateTimeParse1 之外的所有其他故障。
  • dotnet/coreclr#7931 似乎解决了 DateTimeParse1 故障,但我对上述结果使用了一些过时的测试套件(来自 171962f5 提交的测试套件)。

@parjong感谢您提供详细信息!

最后...
这是使用硬 FP ABI 的 Raspberry Pi 2 的最新结果。 :)
445405d84034564a6433074e0f920f74105ba499

=======================
     Test Results 
=======================
# Tests Discovered : 11399
# Passed           : 11035
# Failed           : 0
# Skipped          : 364
=======================
constructing /home/sjlee/unit_test/dumplings.txt
270 minutes and 5 seconds taken to run CoreCLR tests.

testsUnsupportedOnARM32.txt设置如下

JIT/Directed/tailcall/tailcall/tailcall.sh
JIT/jit64/opt/cse/HugeArray1/HugeArray1.sh
JIT/Methodical/tailcall_v4/hijacking/hijacking.sh
JIT/Methodical/tailcall_v4/smallFrame/smallFrame.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof32/_il_dbgsizeof32.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof64/_il_dbgsizeof64.sh
JIT/Methodical/xxobj/sizeof/_il_dbgsizeof/_il_dbgsizeof.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof32/_il_relsizeof32.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof64/_il_relsizeof64.sh
JIT/Methodical/xxobj/sizeof/_il_relsizeof/_il_relsizeof.sh
JIT/Regression/JitBlue/devdiv_902271/DevDiv_902271/DevDiv_902271.sh

好的! 那么现在我们可以对那些不受支持/跳过的那些做些什么呢?

做得好! 做的好各位...! 准备好后,我可以回到基于 R PI3 的加热系统控制器 :)

也很高兴看到正式的 ARM 版本!

我也很想看到正式的 ARM 版本——对于实现这一目标所必需的后续步骤有什么想法吗?

[祝贺所有参与实现这一目标的人——伟大的工作人员]

只是让您知道,如果您想在 Pi3 上运行它,我们在此处提供了一个编译版本(与我们的软件一起打包)

谢谢阿延德! 你知道这是否也会在 Pi2 上执行?

@paultechguy我猜它应该可以在 Pi 2 上正常工作。

我们还没有测试过,但我相当肯定它应该。

也就是说,它可能是 arm7 与 arm6。

*冬眠犀牛有限公司*

Oren Eini* l CEO l *手机:+ 972-52-548-6969

办公室:+972-4-622-7811 *l *传真:+972-153-4-622-7811

2016 年 12 月 5 日星期一晚上 11:22,paultechguy [email protected]
写道:

谢谢阿延德! 你知道这是否也会在 Pi2 上执行?


您收到此消息是因为您订阅了此线程。
直接回复此邮件,在 GitHub 上查看
https://github.com/dotnet/coreclr/issues/3977#issuecomment-264980988
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAHIs8nVGoD0YKE4UkNgD074tTayK9DGks5rFIB5gaJpZM4H7Qi3
.

Pi2是ARM7

是的,我刚刚搜索并找到了 ARM7 笔记。 在可用时为 ARM 正常安装 .NET 内核仍然很棒。 看起来人们很快就会摇滚起来。

@ayende查看您的二进制包,我在 dotnet 包中看到了一些安装脚本内容和已编译的二进制文件,但我仍然处于早期阶段。 你或这里的其他人有没有机会一步一步地告诉我如何让我自己的代码在这个二进制运行时上运行? 我个人并不像在运行系统上踢轮子那样关心从源头构建,而且这里有很多东西要筛选,其中很多都在我的头上,没有深入到构建部分。 通常我愿意贡献更多,但我发现自己最近没有时间做副业,我希望继续专注于我目前的工作,而不是一头扎进这个兔子洞。

抱歉,我想我一定是滚动得太远了,一开始我没有在包中看到 corerun/coreconsole。 我也许可以在没有帮助的情况下玩耍; 如果我回到我的 Pi 时仍然感到困惑,我会报告

@TheXenocide我能够运行控制台应用程序,但还不能运行来自@ayende 的构建的aspnet Web 应用程序

您还需要使用Ubuntu 16.04 映像,安装脚本将确保您安装了所需的软件包。

从您编译的应用程序目录(我刚刚通过 scp 复制了我的)并运行../path_to/Raven/dotnet/corerun MyAppBinary.dll

@Gonkers @TheXenocide @ayende仅供参考。 我们从 core-setup、coreclr 和 corefx 为 Ubuntu 14.04 ARM 和 Ubuntu 16.04 ARM 构建了整个 .NET Core 运行时。 它适用于 Pi2 和 Pi3,它像 Ubuntu 14.04 x64 一样工作,即您不必使用coreruncoreconsole ,只需使用dotnet
您可以在https://github.com/dotnet/core-setup/issues/725 下载 tarball 并找到更多信息。 (您可以在问题末尾找到 tarball。)顺便说一句,我们支持 arm (hardfp) 和 armel (softfp)。

结果(过时。请在 https://github.com/dotnet/core-setup/issues/725 找到最新的)

ubuntu.14.04-arm
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
ubuntu.16.04-arm
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
debian.8-armel
dotnet-debian.8-armel.1.2.0-beta-001271-00.tar.gz
tizen.4.0.0-armel
dotnet-tizen.4.0.0-armel.1.2.0-beta-001273-00.tar.gz

@TheXenocide我刚刚发现@Petermarcu制作的这份指南可能会对您有所帮助。
https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

我尝试在 Orange Pi PC 板(ARM Cortex-A7 四核,H3 Allwinner CPU)上构建 Ubuntu 16.04 ARM,它也很好用。

@Gonkers ,页面https://github.com/dotnet/core/blob/RaspberryPi/samples/RaspberryPiInstructions.md返回 404 Not Found
我也有兴趣在 .net core Raspberry Pi 上启动(它也在 ARM 上):# https://github.com/dotnet/core/issues/140

我无法在 Raspbian 上运行...我尝试“debian.8-armel”和“ubuntu.16.04-arm”

@wang9563检查调用约定。 您可能没有在 Ubuntu 中使用 armel,而是 armhf 格式。

嗯,我可以使用链接的说明在带有 Ubuntu MATE 16.04 的 Raspberry Pi 上运行一个简单的“hello world”.NET Core 应用程序,但不幸的是我无法让我的 ASP.NET Core 应用程序工作。 这是我最新的:

me@my-pi:~/myapp$ ./dotnet publish/<<Company>>.<<Product>>Web.ServiceAdapters.WebSockets.dll


Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.ComponentModel.Primitives, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider.CreateFileWatcher(String root)
   at Microsoft.AspNetCore.Hosting.Internal.HostingEnvironmentExtensions.Initialize(IHostingEnvironment hostingEnvironment, String applicationName, String contentRootPath, WebHostOptions options)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at <<Company>>.<<Product>>Web.ServiceAdapters.WebSockets.Program.Main(String[] args) in C:\Users\davidfallah\Documents\Visual Studio 2015\Projects\<<Product>>web-core\src\<<Company>>.<<Product>>Web.ServiceAdapters.WebSockets\Program.cs:line 10
Aborted (core dumped)

@TAGC这将是一个单独的问题。

@TAGC @khionu我遇到了同样的问题。

我为它创建了一个单独的问题https://github.com/dotnet/coreclr/issues/9168

我按照 Pi 自述文件在 Windows 10 中创建了最简单的“hello world”.NET 核心应用程序,并发布了最新的 2.0.0 测试版 win10-x64(在 Windows 10 桌面上运行良好)、win10-arm 和 win8-手臂。 ARM 版本无法在 Windows 10 中运行(如预期的那样),但也无法在带有 Windows 10 IoT 的 Raspberry Pi 3 中运行。

阅读自述文件,我猜想 win8-arm 版本会起作用。 我对么?

我想我需要以某种方式在 Pi 中安装 .NET 核心运行时(2.0.0),但如果可能的话,找不到任何关于如何安装的文档。

谢谢!

是的,我已经搜索到互联网的尽头,但没有找到一套好的、可靠的关于如何构建和安装最新核心运行时的说明。 :-( 为 ARM 构建 MS 并安装软件包不是很棒吗?

我很确定我们会在发布 ARM 支持时拥有它。 但到目前为止,对于 beta 版本,我会对一个快速而肮脏的解决方法感到满意 :)

@jaestevan @paultechguy我最近在 dotnet 社区站立会议上看到可能对您有所帮助。 免责声明:我还没有尝试过。

那么 Pi 中的 Ubuntu 是运行该项目的唯一方法吗? 我猜它也可以在 Windows 10 IoT 中运行。

@jaestevan看看这里: https ://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

我很好奇你在 Win10 IoT 上遇到了什么? 您不需要安装任何核心运行时。 该指令将运行时与您的应用程序放在一起。

如果它对任何人都有帮助,我将发布关于如何在 RPi3 上安装 dotnet 工具以运行 .net 核心应用程序的说明说明。

  1. 克隆 coreclr 仓库
  2. 编译coreclr

    1. https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-instructions.md安装所有内容

    2. build.cmd arm 发布 skiptests skipbuildpackages

  3. 克隆 corefx 存储库
  4. 编译corefx

    1. build-native.cmd -release -buildArch=arm

    2. build-managed.cmd -release -buildArch=arm -skiptests

  5. 克隆核心设置回购
  6. 编译核心设置

    1. build.cmd -配置发布 -TargetArch arm

  7. 将输出文件复制到 Windows 10 IoT
  8. Get-ChildItem "U:\netcore\corefx\" - 目录 | ForEach-Object { Copy-Item $("U:\netcore\corefx{0}{0}.dll" -f $_.name) "U:\netcore\corefx" }
  9. Get-ChildItem "U:\netcore\corefx\" - 目录 | ForEach-Object {Write-Host $_.name } Remove-Item -recurse

有了这个,我开始运行一个 .NET Core 控制台应用程序和一个 24/7 运行大约 2 个月的 ASP.NET Core Web 应用程序。

编辑:当没有关于如何在 RPi3 上安装的官方说明时,我做了笔记。 考虑首先尝试这些https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

抱歉@jaestevan ,我应该更清楚。 我的意思是指出如何/如何更新框架版本的屏幕截图。 看看这是否会帮助你让它运行。 那是我一段时间以来最大的问题,为正确版本的框架构建。

@Petermarcu按照此说明,我收到 CLR 错误:_无法初始化 CoreCLR,HRESULT:0X80131534_

@Gonkers哦,我明白你的意思了。 谢谢。

@darxis我会在有时间的时候尝试自己构建它,谢谢。

@all :找到这个链接:http: //developers.de/blogs/damir_dobric/archive/2015/09/22/how-to-run-net-core-application-on-pi2-win10-iot-core.aspx我自己还没有尝试过,但我会的。 无论如何,我想当 ARM 支持正式发布时,这应该是一种更清洁的方式。

@jaestevan ,我会再试一次,几周内没有在 Win10 IoT 上做过。 您不必构建完整的堆栈,但它始终是一种选择。

@Petermarcu谢谢彼得,让我知道它是如何工作的。 如果有帮助,我可以将我遵循的详细信息发送给您。

我昨天又试了一次,一切都很好。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifiers>win10-arm</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

dotnet restore
dotnet publish -r win10-arm

然后我将 bin\Debug\netcoreapp2.0\win10-arm\publish\* 复制到 Pi 并执行.\Helloworld.exe

我对正在发生的事情有一个猜测。 您能否运行dotnet --version以确保您使用的是 2.0.0 SDK 并确保您拥有最新的 SDK? 我对预发布 SDK 所做的是将 zip 解压缩到某个位置,打开一个命令窗口,确保我提取 zip 的路径是我路径上的第一件事,然后运行dotnet命令。 目前,由于 SDK 中的一个问题将在接下来的几周内修复,1.0.0 正在胜过 2.0.0。

我刚刚对此进行了试验,并让它与 SDK 版本 2.0.0-preview1-005743 和运行时版本 2.0.0-preview1-001915-00 一起使用。

我已经能够使用最新的 Visual Studio 2017 进行编辑和构建! 一切看起来都很好。

我在https://github.com/sceneskope/PiDotnet有一个存储库,其中有一些可以使用的项目。 我实际上使用 docker 作为我的图像的容器,因为我正在处理的项目必须在多个 PI 上运行。

我还使用 SDK 2.0.0-preview1-005685 和运行时框架 2.0.0-beta-001834-00 创建了一个在 RPI 3 上运行的 .NET Core 应用程序。

本机运行良好(尽管如果尝试在基于microsoft/dotnet-nightly:2.0.0-beta-runtime的 Docker 容器中运行它,我会收到exec format错误)。

Microsoft 映像不适用于 ARM 架构,这就是我创建自己的 docker 映像集的原因! 不过,拥有适当的 Microsoft 图像会很棒。

@nrandell哦,很好,我错过了。 我必须在某个时候尝试一下。

@nrandell这是写在某处的事实吗? 我的意思是没有来自 MS 的 ARM docker 图像。

@MihaMarkic看看https://github.com/dotnet/dotnet-docker/issues/223 。 我想这是官方的。

@nrandell所以,他们最终会为 .net core 2.0 提供一个,但跳过 1.x。

使用 2.0.0-preview1-001978-00 升级和重建所有内容,现在它可以在 Pi 中运行💃

对不起,如果之前已经讨论过这个问题,但是这也可以在 Raspberry Pi Zero 上运行吗?

不幸的是,Pi Zero 只是 ARMv6,但 Mono 可以在那里工作。

2017 年 4 月 17 日星期一 11:58 Andrei Rînea, notifications @github.com 写道:

对不起,如果这已经讨论过,但这会继续吗
树莓派零也是?


您收到此消息是因为您发表了评论。
直接回复此邮件,在 GitHub 上查看
https://github.com/dotnet/coreclr/issues/3977#issuecomment-294452108
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAbA_0ZBbplbgWzERjKkrw-MV7buPiDxks5rw0XvgaJpZM4H7Qi3
.

我认为 pi 1 和 0 的 ARMv6k 与 ARMv6 相比有一些增强。

@wanton7 Hoo boy,还有更多版本让我们保持直截了当吗?

@masonwheeler不确定有什么区别,但是下一个 golang 示例(我认为是 1.9)仍将支持 ARMv6k,但他们正在放弃对 ARMv6 的支持。 所以一定是很重要的事情。

@Petermarcu我建议关闭这个问题; 我们远远超过了“ARM 32 位进步”的标题——我们在 CI 中的 ARM Linux 上运行了数千个测试。 同意?

我同意。 ;)

此页面是否有帮助?
0 / 5 - 0 等级