arch-test - detect architectures your kernel can run binaries of
-
arch-test [-n]
- enumerates the architectures
-
arch-test [-n] [-c
<chroot>] <arch>
- tests a single arch
When called without an argument,
arch-test outputs the list of
architectures executable by your running kernel, one per line, using Debian
arch names.
Libc or other libraries are neither needed nor checked
— an arch is listed if its machine code can be executed and the
appropriate syscall ABI is supported by the kernel. This means, you can run
these architectures in a
chroot or a container, execute them using
multiarch, run static binaries, etc. The ability to run additional
architectures can be gained via
binfmts on Linux, Linux emulation on
BSD, etc.
An architecture is considered runnable only if your kernel can run
unmodified binaries, without extra steps such as recompiling (Raspbian
armhf) or using
brandelf on binaries you'd want to run (FreeBSD
emulation of Linux). Also, as Debian requires 686 on i386 as of the stretch
release, 686 support is checked for.
If
-n is specified,
arch-test will try to disable known emulators
(currently
qemu and
wine). Note that a whole-machine emulator
appears to be native as far as the kernel is concerned.
With
-c <chroot>, the test is done inside a given chroot
(qemu-user before 2.12 required the interpreter to live
inside the
chroot). Root privileges are required here.
When called with an arch name as an argument,
arch-test tests the
specified architecture. A human-friendly message will be printed, and the exit
code can be:
- 0
- congratulations, the arch can be run on your kernel
- 1
- failure
- 2
- cannot check — arch-test lacks a helper for
this arch
- (Shell hint: with set -e you write: ret=0;
arch-test $ARCH || ret=$?)
-
The detection is done by small programs located in
/usr/lib/arch-test/.
These programs check whether the running kernel can execute binaries of a
given architecture. When run, if successful, each such program prints
"ok" on stdout and returns exit code 0.
When the check fails, these helper programs may die horribly — always
with a non-zero exit code. Usually the kernel will notice the incompatibility
and nicely abort the attempt, but in some near-miss cases the failure is more
messy, such as
SIGILL or
SIGSEGV. If you want to run the helpers
directly, you'd want to redirect
stderr to
/dev/null and to
disable core dumps (
ulimit -c 0).