alexcrichton
commented
3 years ago Looks great to me, thanks!
Also wow that ld.so.cache issue sounds spooky...
Closed uweigand closed 3 years ago
alexcrichton
commented
3 years ago Looks great to me, thanks!
Also wow that ld.so.cache issue sounds spooky...
uweigand
commented
3 years ago Looks great to me, thanks!
Also wow that ld.so.cache issue sounds spooky...
I'm still trying to track down the actual root cause, but it's a bit challenging. In particular because even installing gdb or strace into the container pulls in more libraries, which makes the crash disappear :-)
uweigand
commented
3 years ago Looks great to me, thanks!
Also wow that ld.so.cache issue sounds spooky...
Just to follow up on this - the underlying issue has now been fixed in glibc upstream and in the Ubuntu package: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1906250
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 CARGOTARGET..._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.