dotnet core 在 MIPS64 下的移值進度

本文仍處於修訂中html

寫在開始前

咱們的主要業務基於 dotnet core 2.x 與 3.1 完成,目前 dotnet core 3.1 支持的 CPU 架構列表中還不包含龍芯,且在 gitlab issue 中表示官方當前沒有對 MIPS 的支持計劃java

官方支持的具體操做系統與 CPU 架構列表見 [Download .NET Core 3.1](https://dotnet.microsoft.com/download/dotnet-core/3.1git

6月下旬,龍芯團隊宣佈在 dotnet/coreclr 基礎上完成了MIPS64 的移植工做 Open-sourcing CoreCLR MIPS64 Port #38069,計劃實現 3.x 版本並貢獻到上游 dotnet/runtime。github

按照相關 issue 裏的指引,這裏對移值倉庫進行了編譯和一些測試。docker

具體的進度

做爲下游開發者,想知道距離生產環境使用還有多遠,必須先說起 dotnet core 應用程序的發佈/部署方式ubuntu

1. dotnet core 支持兩種方式的發佈/部署

  • 獨立應用(self-contained)
  • 依賴於運行時(runtime-dependent)

前者包含可執行文件(exe),沒法跨平臺;後者生成了跨平臺的二進制文件(dll),須要運行環境預先安裝好運行時。關於部署策略的詳細信息,能夠參考.NET Core application publishing overviewbash

發佈獨立應用須要針對特定操做系統及 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 運行。app

dotnet core 由如下若干部分組成:

mono,unity3d 都是運行時實現,在此略說起

由前文的 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 輸出的是 mips64el 而不是 mips64,前者包含了字節序信息,會致使 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 原創,轉載請註明來自博客園

相關文章
相關標籤/搜索