runtime: Cannot get cross-targeting to work w/Native AOT

Following the instructions at:

My Dockerfile: https://github.com/richlander/dotnet-docker/blob/dotnet-8-samples/samples/releasesapi-aot/Dockerfile.cross-target

Host: Linux kelowna 6.1.38-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Jul 5 23:49:30 UTC 2023 x86_64 GNU/Linux

Docker build: docker build --pull -t app -f Dockerfile.cross-target .

I get this error:

  Generating native code
  ILC: Method '[releasesapi]Program.<Main>$(string[])' will always throw because: Failed to load assembly 'Microsoft.AspNetCore'
  /usr/bin/ld.bfd: unrecognised emulation mode: aarch64linux
  Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om
clang-16 : error : linker command failed with exit code 1 (use -v to see invocation) [/source/releasesapi.csproj]
/root/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/build/Microsoft.NETCore.Native.targets(364,5): error MSB3073: The command ""clang-16" "obj/Release/net8.0/linux-arm64/native/releasesapi.o" -o "bin/Release/net8.0/linux-arm64/native/releasesapi" -fuse-ld=bfd /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/sdk/libbootstrapper.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/sdk/libRuntime.ServerGC.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/sdk/libeventpipe-enabled.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/sdk/libstdc++compat.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/framework/libSystem.Native.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/framework/libSystem.IO.Compression.Native.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/framework/libSystem.Net.Security.Native.a /root/.nuget/packages/runtime.linux-arm64.microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/framework/libSystem.Security.Cryptography.Native.OpenSsl.a --sysroot=/crossrootfs/arm64 --target=aarch64-linux-gnu -g '-Wl,-rpath,$ORIGIN' -Wl,--build-id=sha1 -Wl,--as-needed -pthread -ldl -lz -lrt -lm -pie -Wl,-pie -Wl,-z,relro -Wl,-z,now -Wl,--eh-frame-hdr -Wl,--discard-all -Wl,--gc-sections" exited with code 1. [/source/releasesapi.csproj]
The command '/bin/sh -c dotnet publish -a arm64 -o /app -p:CppCompilerAndLinker=clang-16 -p:SysRoot=/crossrootfs/arm64 releasesapi.csproj' returned a non-zero code: 1

Related: Is this guidance about which NuGet packages to work correct?

https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md#cross-architecture-compilation

Follow up to https://github.com/dotnet/runtime/issues/88942

About this issue

Original URL
State: closed
Created a year ago
Comments: 22 (19 by maintainers)

Most upvoted comments

FYI: I believe I have everything I need working now. Thanks MUCH for the help. It was tremendously useful. The final results were simpler than where I started, which is great. I also learned a fair bit.

I’ll be updating my samples PR in the next 24 hours or so with my results.

https://github.com/dotnet/dotnet-docker/pull/4742

richlander on Jul 24, 2023

https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#qemu

Right, so evidentially docs could use a lighter tone and avoid calling stuff “unsupported” when runtime (the thing which basically matters most for platform support) does not enforce any restrictions for emulators, and neither does the SDK specifically disallows them. If note about unsupported stuff is really necessary in the docs, it should read something like: “QEMU is not officially supported, use it at your own risk”

am11 on Jul 23, 2023

I’m thinking – given the size of these dependencies – that we could offer three sdk variants:

sdk – for CoreCLR apps
aot-sdk – for native AOT apps
aot-cross-sdk – for cross compiling native AOT apps (enables the Dockerfile above)

richlander on Jul 22, 2023

We should be able to get rid of the manually specified ObjCopyName completely in this case. We can either default to lld for cross-compilation; or we can default to the right arch-specific objcopy when cross-compiling. @am11 Do you have a preference?

jkotas on Jul 22, 2023

There is a simpler -p:ObjCopyName=aarch64-linux-gnu-objcopy workaround for it. 😃

am11 on Jul 18, 2023