Add CI for s390x-unknown-linux-gnu #392
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a Docker-based CI job for s390x-unknown-linux-gnu similar to previous existing ones.
Two interesting comments:
I ran into random crashes, which turned out to be caused by issues with handling ld.so.cache in the target ld.so running under qemu. The ld.so.cache file is shared between the host and target ld.so, and is supposedly capable of caching files from multiple architectures in a single file. However, in the default Ubuntu multi-arch setup, unless you install the s390x version of libc (from ports), ld.so.conf will never refer to any s390x libraries in the first place, so the target ld.so will never find any cache entry. That in itself should still be fine, but in some cases the target ld.so will simply crash in that scenario. I haven't found out the exact cause, but it is related to which particular set of libraries happens to be installed on the host ... As a workaround, I'm now simply deleting the ld.so.cache file in the container image.
The concurrent-panics.rs test doesn't work because it spawns a second executable, which doesn't use the CARGO_TARGET_..._RUNNER wrapper. I've tried to enable the automatic binfmt_misc based qemu handler, but it looks like this doesn't work in a docker container (at least not on the github installation) since binfmt_misc handlers are shared between the container and the host running the container. As a workaround I'm simply skipping that test on s390x, as is already done (for the same reason) on arm and aarch64.