Package: wnpp Severity: wishlist Owner: Adam Borowski <kilob...@angband.pl>
* Package name : arch-detect Upstream Author : me * URL : https://github.com/kilobyte/arch-detect * License : MIT Programming Lang: mostly assembler Description : detect architectures supported by your machine/kernel This package lets you enumerate architectures that your kernel can run. The check is for the ability to run machine code and supporting appropriate syscall ABI -- you may need to install userland libraries in a chroot, container or via multiarch to actually execute non-static binaries of such architectures. . Architectures detected by this version of arch-detect are: * amd64, i386, x32 * mips, mipsel, mips64, mips64el * arm, armel, armhf, arm64 * powerpc, ppc64, ppc64el * m68k * sh4 * s390x * sparc64 * illumos-amd64 * win32, win64 My reason here is that x32 can't be detected other than trying a syscall and seeing if it fails. But then, we don't want a 344 byte package -- so here's one that handles all release archs and most -ports ones. Most of these can be detected by reading /proc and binfmts, but that's neither easy nor reliable -- testing empirically works better. Some quirks: * ppc64el: I check "mtvsrd r0, r0" to fail qemu if it suffers from #813698 * armhf: "dmb" nicely SIGILLs on RPi 1, are there other ARMv7-but-not-armhf in the wild worth checking? * arm: untested (does anyone have that old hardware?) -- fails on all porterboxes but succeeds on both kernel 3.8 on Odroid-U2 and 4.1 on Raspbian RPI 1. Archs that are missing: * kfreebsd-*: no cross binutils in unstable (uses a different format, unlike hurd and Solaris which share it with Linux) * hurd: how do you even do syscalls there?!? Trying to figure it out exhausted my attention span. RTFSing glibc, I see it's something bizarre: _exit() requests some server to terminate the process then goes into an endless loop of dividing 1/0. * alpha: no machine to test it on, I'm reluctant to trust qemu exclusively * hppa: no machine to test, not even supported by qemu * ia64: no cross binutils * sparc: binutils can multilib it, does anyone still want it? * powerpcspe: no machine, debootstrap in qemu fails Naming issues: * illumos-amd64: (Solaris): dpkg's table has different names; I used this one as it's an established unofficial port in a pretty good shape; you may argue a different name though -- like, something that mentions that this syscall ABI works on real Solaris... * win32, win64: should I name them -i386, -amd64? Not sure if detecting them even makes sense -- binfmts exist but you're not going to chroot/ multiarch those...