[ARM32/Linux] CoreCLR building issues for ARM32 on Linux

[hseok-oh]

We have some issues for ARM 32bit cross building on Linux. Especially, we need to clear some of these tasks to enable core-setup for ARM32. (dotnet/core-setup#725)

Packages build

• Update CoreCLR to generate nuget packages of CoreCLR (PR: First step to create nuget packages for ARM32/Linux coreclr#8421)
• Enable CoreCLR Pipeline build support for Linux for Arm32 and publish packages (issue https://github.com/dotnet/coreclr/issues/8639)
• Build libcoreclrtraceptprovider.so (issue dotnet/coreclr#8684)
• Generate *.ni.dll files using x86 hosted crossgen (issue https://github.com/dotnet/coreclr/issues/8647)
• pass unit test

Fix build script for cross build

• Fix build script for cross-architecture component (Issue: Linux cross build: cmake variable setting #7098 PR: Fix buildsystem for linux cross-architecture component build coreclr#8646)

CI support

• Update CI to use Docker images for ARM32 CI (issue: dotnet/coreclr#9273, [ARM/CI] ARM CI script for arm and armel coreclr#9445 PR: dotnet/coreclr#10185)

[hseok-oh]

cc @chunseoklee @jyoungyun @idkiller
@gkhanna79 @janvorli

[gkhanna79]

How does this relate, tracking wise, to https://github.com/dotnet/core-setup/issues/725?

[hseok-oh]

@gkhanna79 I also think not all of tasks in this issue are related to dotnet/core-setup#725 directly.

We may generate package file for Linux ARM32 by task 1 (Update CoreCLR to generate nuget packages of CoreCLR). But we need additional tasks to generate more complete package. (such as libcoreclrtraceptprovider.so , crossgen and *.ni.dll)

[SteveDesmond-ca]

I had previously noticed that libcoreclrtraceptprovider.so is explicitly ignored/removed from the things to build for non-Windows ARM...was this based on a previous assumption/requirement that is no longer true? I'm happy to pick that one up if no one else has.

As for the crossgen pieces, here is how I was doing it, quick and dirty, though that requires sudo'ing, which is probably not the best way.

[gkhanna79]

@hseok-oh I would suggest we have a single issue to track all open items for Linux Arm32 E2E bringup so that it serves as a reference of the current status. Can you please reference these as "CoreCLR Arm32 issues" from https://github.com/dotnet/core-setup/issues/725 and use this issue as a central issue for all CoreCLR for Linux Arm32 issues?

[gkhanna79]

@SteveDesmond-ca The repo builds clean with libcoreclrtraceptprovider.so for 16.04. However, it does not build clean for Ubuntu 14.04 and, hence, being excluded.

requires sudo'ing, which is probably not the best way.

Yes, and it is blocker for automation to use that approach. Hence, we need to have a x86 hosted crossgen that generate Arm32 code so that it just runs in the natural expected manner.

[hseok-oh]

@gkhanna79 I updated dotnet/core-setup#725 and this issue. I agree with you.

[hqueue]

I also agree that this issue handle all CoreCLR related issues for Arm32 bringup.

@gkhanna79 what does "E2E" in "Arm32 E2E bringup" stand for?

[gkhanna79]

@hqueue E2E stands for End-to-End.