Irgendwas mit Gartenbau...

So in our latest little project, we have dependencies left and right, and BOTH agree that arm64 and aarch64 are not something that they need to support, because they’ve never heard of it.

The insulting bit is that that build is explicitly made to trip in the shared-library loader/cmake respectively, because they didn’t want to figure out which host-tuple/triple to use! The code compiles just fine!

Because life is too short (I have a pull-request for the left-dependency, but still need to figure out what to do on the right), I decided that the Apple M1 Ultra should be juicy enough to do full emulation in a VS Code DevContainer of a linux/amd64.

Turns out there are 2 1/2 strings you need to pull to get this to work:

  1. Tell VSCode to build an amd64 Docker image
  2. Tell VSCode to launch an amd64 Docker container because it’s apparently bad at listening
  3. Tell VSCode in the container that, no, you really don’t want aarch64 binaries for the host that you’re running on, but indeed x86 will do just fine, thank you.

For (1) & (2), you need a Dockerfile like this:

{
    "name": "AMD64",
    "build": { "dockerfile": "Dockerfile",
    "context": "../SmartNode",
    "options": ["--platform", "linux/amd64"]
    },
    "runArgs": ["--platform", "linux/amd64"],
    "customizations": {
        "vscode": {
            "extensions": ["ms-dotnettools.csdevkit"]
        }
    }
}

“Why (3)?” you ask? Well:

$ uname -m
x86_64
$ dotnet run --project Project.csproj
Using launch settings from Project/Properties/launchSettings.json...
Unhandled exception: An error occurred trying to start process '/workspaces/Project/bin/Debug/net8.0/Project' with working directory '/workspaces/Project'. No such file or directory
$ file /workspaces/Project/bin/Debug/net8.0/Project
/workspaces/Project/bin/Debug/net8.0/Project: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1 ...

So you actually want/need:

$ dotnet run -a x64 ...

Oh, and for some reason (probably for the same reason I need the -a x64), the IDE is really b0rked; I guess not all VSCode-subcomponents running inside the container got the memo.

Hack the planet!

Trackback: Mastodon