dotnet core 在 MIPS 下的移值进度

本文仍处于修订中

写在最先前

我们的主要营业基于 dotnet core 2.x 与 3.1 完成,现在 dotnet core 3.1 支持的 CPU 架构列表中还不包罗龙芯,且在 gitlab issue 中示意官方当前没有对 MIPS 的支持设计

更详细操作系统与 CPU 架构列表见 [Download .NET Core 3.1](https://dotnet.microsoft.com/download/dotnet-core/3.1

6月下旬,龙芯团队宣布在 dotnet/coreclr 基础上完成了MIPS64 的移植事情 Open-sourcing CoreCLR MIPS64 Port #38069,设计实现 3.x 版本并孝敬到上游 dotnet/runtime。

根据相关 issue 里的指引,这里对编译了移值事情,举行了一些测试。

详细的进度

作为下游开发者,想知道距离生产环境使用另有多远,必须先提及 dotnet core 应用程序的公布/部署方式

1. dotnet core 支持两种方式的公布/部署

  • 自力应用(self-contained)
  • 依赖于运行时(runtime-dependent)

前者包罗可执行文件(exe),无法跨平台;后者生成了跨平台的二进制文件(dll),需要运行环境预先安装好运行时。关于部署计谋的详细信息,可以参考.NET Core application publishing overview

公布自力应用需要针对特定操作系统及 CPU 架构编译并包罗响应运行时,现实开发中我们以依赖于运行时的方式交付,配合预先准备的包罗运行时(runtime)的 docker 镜像完成部署。

微软官方 aspnet core 示例中的 Dockerfile

# ... 
FROM mcr.microsoft.com/dotnet/core/runtime:3.1
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet","dotnetapp.dll"]

2. dotnet core 的组成部门

作为编译型语言,和 Java 源代码被 javac 编译为字节码再交由 JVM 运行一样,csharp/vb.net 等源代码被编译为内容主要是 IL(中心语言,平台无关)的 Windows PE 文件(可用于所有操作系统),然后交由 CLR 运行。

dotnet core 在 MIPS 下的移值进度

dotnet core 由以下若干部门组成:

mono,unity3d 都是运行时实现,在此略提及

UiAutomator源码学习(2)– UiAutomationBridge

由前文的 Dockerfile 可以看到,依赖于运行时的 dotnet core 应用通过 dotnet xxxx.dll 运行,这里有若干层意义:

  1. dotnet 提供了 Host(宿主/主机)能力,由于依赖于运行时(runtime-dependent)的 dotnet core 应用并不是可执行文件,需要类似 JVM 的机制运行起来
  2. dotnet 以交互式下令将 runtime 与 sdk 聚集在一起,成为完整的工具链

而 dotnet/coreclr 编译效果并不包罗可执行的 dotnet 下令,运行/测试已公布的 dotnet core 应用有以下选择

当前的交付/部署体验都是通过 dotnet 下令举行的,获取该下令需要更多的事情,接下来是龙芯团队的移值事情的说明。

龙芯团队的事情

龙芯团队的事情在 19 年 7 月份最先,那时的 dotnet core源码结构、功效与现在的调换如下表。

原堆栈 移值堆栈 功效 释出 调换
dotnet/coreclr gsvm/coreclr 运行时源码 合并入 dotnet/runtime
dotnet/corefx gsvm/corefx 尺度库源码 2020/7/7 合并入 dotnet/runtime
dotnet/core-setup gsvm/core-setup 编译堆栈 2020/7/7 合并入 dotnet/runtime
dotnet/cli 下令行工具链源码 合并入 dotnet/sdk

dotnet/core-setup 对照特殊,它是用来用来编译 runtime,类库和宿主程序的堆栈,注重直到这一步 dotnet 下令才终于可用。

内陆编译 gsvm/coreclr

龙芯团队首份释出的源码是 dotnet/coreclr。根据社区的相同纪录,由于依赖庞大,建议基于 docker 举行编译

git clone https://github.com/gsvm/coreclr.git
cd coreclr
docker run --rm -v $(pwd):/coreclr -w /coreclr aoqi/dotnet-buildtools:loongson3a-loongnix-1.0-llvm8ld ./build.sh -skiptests -ignorewarnings release

注重使用docker manifest inspect可知,镜像 aoqi/dotnet-buildtools:loongson3a-loongnix-1.0-llvm8ld 仅适用于龙芯操作系统,更多内容请参考 龙芯3A4000 开发机编译CoreCLR 环境 #6

作者使用的服务器使用 uname -p 输出的是 mips64 而不是 mips,前者会导致 gsvm/coreclr 中相关剧本对 CPU 架构的断言失败,被相关人士以为违反了分发版本的命名规则,以是后续使用了交织编译。

交织编译 gsvm/coreclr

若是手边已经有 x64 服务器,基于 docker 举行交织编译也是不错的选择,我们可以将编译效果 scp/rsync 到龙芯服务器。

docker run --rm -v $(pwd):/coreclr -w /coreclr -e ROOTFS_DIR=/crossrootfs/mips64el aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el ./build.sh release ignorewarnings mips64 cross skipcrossgen

编译耗时不多,但链接步骤需要使用大量的内存,作者最初使用了一台腾迅云低配主机都在进度 87% 时失败,替换使用一台更高设置服务器后编译乐成,相关讨论可见于 cross compile failed …

交织编译 gsvm/corefx

7月7日龙芯团队释出了 dotnet/corefx 和 dotnet/core-setup 堆栈,编译方式如下,参考 cross-building.md

git clone https://github.com/gsvm/corefx.git
cd corefx
docker run --rm -v $(pwd):/corefx -w /corefx -e ROOTFS_DIR=/crossrootfs/mips64el aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el-corefx ./src/Native/build-native.sh mips64 debug cross ignorewarnings cmakeargs -DOBJCOPY=/usr/lib/llvm-6.0/bin/llvm-objcopy

内陆编译

docker run --rm -v $(pwd):/corefx -w /corefx -e ROOTFS_DIR=/crossrootfs/mips64el_loongnix aoqi/dotnet-buildtools:x86_64-ubuntu-16.04-c103199-20180628134544-upstream-cross-mips64el-corefx ./src/Native/build-native.sh mips64 debug cross ignorewarnings cmakeargs -DOBJCOPY=/usr/lib/llvm-6.0/bin/llvm-objcopy

leoninew 原创,转载请注明来自博客园

原创文章,作者:28rg新闻网,如若转载,请注明出处:https://www.28rg.com/archives/21967.html