Build failure with GCC 10 in systrap/sysmsg about gvisor HOT 3 OPEN

Thanks for the detailed and well-researched bug report.

Changing the optimization level of GCC 10 may well fix this problem, but in general gVisor isn't regularly compiled across multiple GCC versions and tested to ensure that all of them work the same way, with the same level of performance, etc. It is for this reason that the gVisor Makefile includes all this weird logic around spawning a bazel server Docker container and executing all the compilation steps in there; that way the GCC version is determined by the image version used by that container, rather than whatever is on the host.

I suggest adjusting your workflow to use a similar approach (e.g. by using make rather than bazel) in order to not have this problem. Is this an option for you?

from gvisor.

Yes and no, we don't have nested docker support in our CI system easily currently, so using the docker builder would take some work to setup.

Is there any sort of guarantee that binaries built from that builder will work on any Linux host system? We don't use Ubuntu for our metals and part of the reason we build from the same OS as we deploy on is that we've run into issues with pretty much every toolchain leaking host details into their artifacts (glibc is especially notorious for this with its symbol versioning). I understand bazel is much better about this than cmake or autotools, but without a sysroot it's still dependent on the host.

from gvisor.

runsc is a static linked binary and it has to work on any host system. We build runsc in other environment than where we use it and I don't remember any issues with this.

from gvisor.