Add linux-loongarch64 images

[am11]

Upstream dotnet/arcade#15370

Fixes #856

[akoeplinger]

Awesome, thank you!

[akoeplinger]

@am11 FYI there's this warning in the log:

/scripts/eng/common/cross/install-debs.py:273: DeprecationWarning: Python 3.14 will, by default, filter extracted tar archives and reject files or modify their metadata. Use the filter argument to control this behavior.
   tar.extractall(path=extract_dir, filter=None)

[am11]

The old behavior was:

• no warning
• extract whatever (in-tree, outside of the destination tree)

new behavior:

• warn when outside of the destination tree
• safe extraction (not sure if it is effective but I'll confirm once the image is built)

We want the old behavior because we are essentially extracting in /etc/usr/bin etc. which requires outside of the destination tree extraction.

Thank you! I spend my holidays working on it. Hopefully it will be enough to cross-build runtime/diagnostics. Soon we will find out. 😅

[am11]

Fixed by dotnet/arcade#15372. Note python3.14 will be released next week and currently in rc2. This warning is coming from 3.12 so it's harmless as of today. 🙂

[am11]

@xen0n @SixWeining, for dotnet runtime, we build our own copy of llvm-toolchain for the required components and architectures. For riscv64, all we had to do was to add this line https://github.com/dotnet/dotnet-buildtools-prereqs-docker/pull/1098/files#diff-6523ee70a4b5d768c077dad5e944e632e502c99fe47c807809946e44b5f2e13a to light up the arch support with clang/llvm-config.

I updated the line similarly for LoongArach in this PR, and the logs (https://dev.azure.com/dnceng-public/public/_build/results?buildId=905886&view=logs&j=9aada89a-2e24-5acb-2807-6900158b9cce&t=6f3c41b4-0b5c-55eb-81af-364314aaa449) seem to have built all the default targets, but clang -print-targets is not showing us LoongArch:

$ docker run --rm \
    mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-net10.0-cross-loongarch64-musl \
    clang --print-targets

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

and

$ docker run --rm \
    mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-net10.0-cross-loongarch64-musl \
    llvm-config --targets-built

X86 AArch64 ARM PowerPC RISCV SystemZ

Any ideas what's going on? This is llvm 19, we can switch to llvm 20 if you think that would help.

[am11]

Ah never mind this is a caching issue with the layers. The builder layer mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-net10.0-crossdeps-builder-amd64 does show loongarch. But since the wrapper layer azurelinux-3.0-net10.0-crossdeps-llvm-amd64 is not built, we get this weird old+new state.

@mthalman are we happy with the current layering? I think I'd need to just touch azurelinux-3.0-crossdeps-llvm-net10.0-local to trigger its rebuild.