Numerous bug fixes for musl and other images.

[Alexhuszagh]

Provide qemu-runner that allows native or non-native for any architecture, and install qemu-user binaries for x86 musl images. In addition, create symlinks so dynamically-linked binaries can be run, including for C++, with musl images.

Adding qemu-user runners is also useful for running dynamically-linked x86 binaries, since otherwise they may be unable to find the linked musl libc, and we cannot install it in /lib or /usr/lib due to conflicts with the system.

[Alexhuszagh]

This is a very preliminary draft (will need a CHANGELOG entry once it's more established), but it aims to do the following:

• Allow musl images to run dynamically-linked binaries
• Add qemu-user and native runners for all musl images (very handy for x86)
• Provide a single script for symlinking all musl libc locations, to ensure it is found.

I also hope this will close #902, but this isn't there yet.

This has fixed C++ support and other issues in a lot of targets, with the only ones failing with C++ or dynamic library support now are:

• aarch64-unknown-linux-musl
• mips64el-unknown-linux-muslabi64
  • undefined reference to symbol '__trunctfsf2@@GCC_3.0'
  • error adding symbols: DSO missing from command line
• mips64-unknown-linux-muslabi64
  • undefined reference to symbol '__trunctfsf2@@GCC_3.0'
  • error adding symbols: DSO missing from command line
• x86_64-unknown-linux-musl
  • /lib64/ld-linux-x86-64.so.2 (causes segfault)

So, 2 targets link to glibc, and 2 targets have symbol errors in GCC. Those 2 symbol errors are issues with missing symbols from soft-float builtins.

[Alexhuszagh]

bors try

[bors]

try

Build failed:

• conclusion

[Alexhuszagh]

I've fixed the bug with CI trying to use qemu-system (It had previously hard-coded qemu-arm, so CROSS_RUNNER was being ignored) for armv7-unknown-linux-gnueabi, so this should be ready for review. All targets pass (well, armv7-unknown-linux-gnueabi should pass).

[Emilgardis]

looks good!

Would it make sense to actually have MUSL_SYSROOT as an ENV instead of simply a build arg?

[Alexhuszagh]

looks good!

Would it make sense to actually have MUSL_SYSROOT as an ENV instead of simply a build arg?

If so we should probably prefix it as CROSS_MUSL_SYSROOT, but absolutely.

[Emilgardis]

bors r+
🚀

[bors]

Build succeeded:

• conclusion