The use of Docker in this context is incidental, giving me a way to give me a way to share a small yet useful ARM64 binary with you for testing. However, Docker also uses QEMU in this fashion:
$ docker run iperf3
WARNING: image platform (linux/arm64) does not match the expected platform (linux/amd64)
That’s the same binary but now running inside the container we created above before extracting the statically-linked binary from it via a tarball. Docker yells about the platform mismatch, but it then does run.
I forgot to point out that “docker” is actually an alias for Podman on the test system, which fully satisfies your wish for using only things that come with the platform, no third-party programs, Podman being a Red Hat project.
My example used a statically-linked binary to keep things simple, simplifying cross-platform execution, but for larger programs needing third-party libraries, containerization gives you another benefit here: a way to cart around the rest of the platform needed to run your ARM binaries.
3 thoughts on - Emulate ARM ?
surely I meant ARM, surely :)
With QEMU:
$ uname -r
5.14.0-284.30.1.el9_2.x86_64
$ sudo dnf install qemu-user-static-aarch64
$ docker pull –platform=linux/arm64 tangentsoft/iperf3
$ docker export $(docker create –name iperf3 tangentsoft/iperf3) > iperf3.tar
$ tar xf iperf3.tar
$ file bin/iperf3
bin/iperf3: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=254575ed4ae36c21c317691a8008f3382eb7225e, stripped
$ bin/iperf3 -s
———————————————————–
Server listening on 5201 (test #1)
———————————————————–
That’s an ARM64 binary running on x86_64 via the magic of the kernel’s binfmt feature <https://docs.kernel.org/admin-guide/binfmt-misc.html>.
The use of Docker in this context is incidental, giving me a way to give me a way to share a small yet useful ARM64 binary with you for testing. However, Docker also uses QEMU in this fashion:
$ docker run iperf3
WARNING: image platform (linux/arm64) does not match the expected platform (linux/amd64)
That’s the same binary but now running inside the container we created above before extracting the statically-linked binary from it via a tarball. Docker yells about the platform mismatch, but it then does run.
I forgot to point out that “docker” is actually an alias for Podman on the test system, which fully satisfies your wish for using only things that come with the platform, no third-party programs, Podman being a Red Hat project.
My example used a statically-linked binary to keep things simple, simplifying cross-platform execution, but for larger programs needing third-party libraries, containerization gives you another benefit here: a way to cart around the rest of the platform needed to run your ARM binaries.