Add scripts to validate target info.

[Alexhuszagh]

Attempts to recreate the table present in README.md, which
can extract the target information for a single target
or for all targets.

Should currently support the following targets:

• Android
• glibc
• musl
• MinGW
• FreeBSD
• NetBSD
• newlib

Closes #686.

This produces the following table:

Target	libc	GCC	C++	QEMU
aarch64-linux-android	9.0.8	9.0.8	✓	5.1.0
aarch64-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
aarch64-unknown-linux-musl	1.2.0	9.2.0	✓	5.1.0
arm-linux-androideabi	9.0.8	9.0.8	✓	5.1.0
arm-unknown-linux-gnueabi	2.23	5.4.0	✓	5.1.0
arm-unknown-linux-gnueabihf	2.17	8.3.0	✓	5.1.0
arm-unknown-linux-musleabi	1.2.0	9.2.0	✓	5.1.0
arm-unknown-linux-musleabihf	1.2.0	9.2.0	✓	5.1.0
armv5te-unknown-linux-gnueabi	2.27	7.5.0	✓	5.1.0
armv5te-unknown-linux-musleabi	1.2.0	9.2.0	✓	5.1.0
armv7-linux-androideabi	9.0.8	9.0.8	✓	5.1.0
armv7-unknown-linux-gnueabihf	2.23	5.4.0	✓	5.1.0
armv7-unknown-linux-musleabihf	1.2.0	9.2.0	✓	5.1.0
i586-unknown-linux-gnu	2.23	5.4.0	✓	N/A
i586-unknown-linux-musl	1.2.0	9.2.0	✓	N/A
i686-linux-android	9.0.8	9.0.8	✓	5.1.0
i686-pc-windows-gnu	N/A	7.5	✓	N/A
i686-unknown-freebsd	1.5	6.4.0	✓	N/A
i686-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
i686-unknown-linux-musl	1.2.0	9.2.0	✓	N/A
mips-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
mips-unknown-linux-musl	1.2.0	9.2.0	✓	5.1.0
mips64-unknown-linux-gnuabi64	2.23	5.4.0	✓	5.1.0
mips64el-unknown-linux-gnuabi64	2.23	5.4.0	✓	5.1.0
mipsel-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
mipsel-unknown-linux-musl	1.2.0	9.2.0	✓	5.1.0
powerpc-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
powerpc64-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
powerpc64le-unknown-linux-gnu	2.23	5.4.0	✓	N/A
riscv64gc-unknown-linux-gnu	2.27	7.5.0	✓	5.1.0
s390x-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
sparc64-unknown-linux-gnu	2.23	5.4.0	✓	5.1.0
thumbv6m-none-eabi	2.2.0	4.9.3		N/A
thumbv7em-none-eabi	2.2.0	4.9.3		N/A
thumbv7em-none-eabihf	2.2.0	4.9.3		N/A
thumbv7m-none-eabi	2.2.0	4.9.3		N/A
x86_64-linux-android	9.0.8	9.0.8	✓	5.1.0
x86_64-pc-windows-gnu	N/A	7.3	✓	N/A
x86_64-unknown-freebsd	1.5	6.4.0	✓	N/A
x86_64-unknown-linux-gnu	2.17	4.8.5	✓	4.2.1
x86_64-unknown-linux-musl	1.2.0	9.2.0	✓	N/A
x86_64-unknown-netbsd	9.2.0	9.4.0	✓	N/A

There's a few mild differences here, but I think they're correct:

• FreeBSD uses the symbol versioning for libc.
• Android libc uses the LLVM version, and the compiler version isn't the native GCC toolchain either.

A few notes on how this works:

• C++ support is checked by there being a C++ executable, and it can compile a simple program (see below):
• Compiler version is detected by the output of GCC or Clang by a regular expression.
• Qemu version is detected by the presence of a Qemu binary and extracted via a regular expression.
• libc verson is quite intricate, but interesting:
  • If Android, the libc version is just the compiler version (Clang == LLVM).
  • If musl, we execute the binary and extract the version via a regular expression.
  • If glibc, we use the versioned filenames to get the version (libc-2.17.so).
  • If newlib, we use dpkg to get the package version which has the newlib version.
  • For FreeBSD, we wrote the FreeBSD version to file, and then match that to the libc version.
  • For NetBSD, we can read the version from the libc.so symbols, grepped for NetBSD.
  • For Windows, intentional passthrough.

C++ Program

This may fail in the case we cannot compile a C program to begin with (AKA, newlib, which we have missing startfiles, etc.). This really doesn't matter right now, since none of these bare-metal targets support C++, although in the future we may want to add -nostartfiles during compilation.

#include <iostream>
int main() {
    std::cout << "Testing this" << std::endl;
}

[Alexhuszagh]

Other solutions could be to tag images based on the toolchain version, but this might be difficult since we likely also want to tag them based on the cross release version.

[Alexhuszagh]

This could also potentially iterate over all the Dockerfiles in the docker/ directory, which would make this work if future targets are added (see: thumbv7neon).

[Emilgardis]

I think these should live in a folder, not at the root. Maybe ci ?

I'd also prefer if this wasn't bash, but rust, but we can make that transition later

[Alexhuszagh]

I think these should live in a folder, not at the root. Maybe ci ?

I'd also prefer if this wasn't bash, but rust, but we can make that transition later

Sure sounds like a good idea. I've updated it to read from the CI for the targets, and use -nostartfiles if the image uses newlib (IE, bare-metal), so this should be future resilient.

[Alexhuszagh]

I think these should live in a folder, not at the root. Maybe ci ?

Done, sounds like a perfect place.

I'd also prefer if this wasn't bash, but rust, but we can make that transition later

That sounds good, since we have regex as a dependency we should have everything we need.

[Emilgardis]

Seems they lost x when moved

[Emilgardis]

r+ me when executable set again

[Alexhuszagh]

bors r=Emilgardis

[bors]

Build succeeded:

• conclusion