CI: add targets for armv7, aarch64, s390x, ppc64le

[triplef]

More CI! This uses the Run-On-Arch Action to build inside an architecture-specific Docker container running Ubuntu, that gets run with qemu-static (from what I understand). This vastly expands our architecture/CPU coverage, unfortunately at the expense of CI runs taking more than twice as long (~1h). Let me know if this is not a good tradeoff, or if we should remove any archs that are not interesting in order to speed this up a bit (I didn’t add builds for the gnustep-1.9 runtime for this reason as I’m not sure why anyone would use it, but could easily add it).

The builds look mostly good except for the following, which I’ve flagged as being allowed to fail for now:

• Failed test NSRunLoop/thread.m (under aarch64 Clang and ppc64le GCC/Clang):
  thread.m:192 ... A loop with no inputs or timers will exit
• Various failed tests like this under ppc64le (Clang/GCC), which I think happen when tests throw exceptions:

   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
   /workspace/build/bin/gnustep-tests: line 413: 23984 Segmentation fault      (core dumped) $RUN_CMD
   Failed file:     NSZone.m aborted without running all tests!
  

I also excluded the armv7 Clang combination, as it fails due to this CMake bug, which is fixed in newer CMake releases. Ubuntu 20.04 currently ships with CMake 3.16.3 which still has this bug. Not sure if there’s an easy way to install a newer CMake? Here’s a CI run with the full matrix for reference.

Finally, the s390x Clang combination is excluded due to the following error building libdispatch (somehow passing -Wno-error=unneeded-internal-declaration in CMAKE_C_FLAGS did not change anything):

allocator.c:708:1: error: function '_dispatch_malloc_continuation_alloc' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
_dispatch_malloc_continuation_alloc(void)
^
allocator.c:719:1: error: function '_dispatch_malloc_continuation_free' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
_dispatch_malloc_continuation_free(dispatch_continuation_t c)
^
allocator.c:771:20: error: function '_dispatch_continuation_alloc_once' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static inline void _dispatch_continuation_alloc_once(void) {}

By the way, the Run-On-Arch action also supports Debian and Arch Linux in addition to Ubuntu, which I guess would be nice to use to expand OS coverage, but I wasn’t sure how to install the necessary packages on these systems (at least Arch’s package database seems to be missing many packages that we require, not sure about Debian).

Also removes installation of libkqueue-dev package as it is not used by libdispatch, updates dependencies from libobjc-9-dev to libobjc-10-dev, and adds -q flag to git clone to prevent progress logs from spamming logs.

[triplef]

Not sure if anyone would use the s390x, I could also see us removing it from the matrix. Is ppc64le of interest?

Mainly I’m interested in running the tests on ARM CPUs to get some coverage for Android.

[rfm]

It's great to be able to build and run tests on as many systems as possible, so this is really good work.
However, I do have a reservation: If we can't actually support a system and fix any bugs we find, then it's probably not productive to have tests failing and raising alerts for that system.

I think that means that we need to have a way to automatically set up the same sort of system that the tests are being run on, with dev tools like gdb installed, in such a way that we can get on to it and debug/test/fix any issues. Is there any way that we can do that?

[triplef]

Very good point @rfm. It should be possible to use the same Docker images used on CI also locally, install gdb etc., and this should automatically use QEmu for the CPU emulation.

I'll try to come up with some instructions how to do so.

[triplef]

Here’s an example for how to run a Docker container like the ones used in the CI locally. This leverages Docker’s multi-arch support and will automatically use qemu under the hood to emulate the CPU.

I’ve only tested this on macOS, but I think it should work the same on Linux. Requires Docker to be installed.

# Replace "arm64v8" below with any of the following architectures:
# arm32v7, arm64v8, ppc64le, s390x, riscv64

docker pull arm64v8/ubuntu
docker create -it --name gnustep-arm64v8 arm64v8/ubuntu # this will output a warning about non-matching platforms, which can be ignored
docker start -ai gnustep-arm64v8
# => starts shell in container, just use "docker start ..." for subsequent runs

# inside container:
apt-get update
apt-get install git make cmake clang lldb pkg-config libgnutls28-dev libffi-dev libicu-dev libxml2-dev libxslt1-dev libssl-dev libavahi-client-dev zlib1g-dev gnutls-bin libpthread-workqueue-dev

export CC=clang
export CXX=clang++
mkdir /workspace
cd /workspace
git clone https://github.com/gnustep/libs-base.git
cd libs-base

# install dependencies
DEPS_PATH=/workspace INSTALL_PATH=/usr/local LIBRARY_COMBO=ng-gnu-gnu ./.github/scripts/dependencies.sh

# install base
. /usr/local/share/GNUstep/Makefiles/GNUstep.sh
./configure
make -j`nproc`
make install

# run tests
make test

Unfortunately I’ve however been unable to get the debugger to work on macOS, but I think this might be a macOS-specific issue and hopefully this will work on Linux:

$ lldb cat
(lldb) target create "cat"
Current executable set to 'cat' (aarch64).
(lldb) r
error: process launch failed: 'A' packet returned an error: 8

[gcasa]

@rfm @triplef has this been abandoned?

[triplef]

I’d be happy to merge this if its thought valuable.

@rfm are the instructions above sufficient, and is there a better place to document this than here in the issue?