envoy: gcc build is failing for test targets that depend on //source/exe:envoy_common_lib
The //source/exe:envoy_common_lib target builds all extensions and as a result creates a huge list of virtual include paths to each extension directory (which by themselves are also long). In this case gcc fails to spawn its frontend:
gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus’: execv: Argument list too long
As a short term solution the three test targets have been modified to depend on the //source/exe;envoy_common_with_core_extensions_lib which only includes core extensions. Two tests in question do not need all extensions, and one is enough to test on clang.
Going forward I’m engaging with the bazel team to see how this can be addressed.
Plan B is to ask RBE team to increase ulimit -s on RBE VMs.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (24 by maintainers)
Yes, I agree 30% is not quite “way down the road” as I thought. I’ll start on fixing the include paths.
Here is I think the way forward with this issue. The https://docs.bazel.build/versions/master/be/c-cpp.html#cc_library.implementation_deps solves the issue on gcc but we need to wait a few weeks for this to be released. Bazel then will need to be updated in our build config and toolchains. I do not think this should be a problem. This should kick the can way down the road (quite possibly for good), when we accumulate enough core libraries to hit this issue again.
If we want to solve this issue once and for all we need to wean ourselves from using
include_prefix. This will be jumbo refactor that will requires us using full include paths to headers inincludeandsource. So it will be#include "include/common/callback.h"instead of current#include "common/callback.h"There definitely some loss of aesthetics.How do people feel about using full paths in
#includedirectives? Please indicate with thumbs up/down emoji.We are actively working on resolution. I expect a workaround by tomorrow.
Deprecation of envoy_include_prefix usage to strip out include/ and source/ seems tractable. Should we make that change?
https://github.com/envoyproxy/envoy/blob/19c59da575e0fdc0ca02362c9b6f79b6b7fc80d3/bazel/envoy_library.bzl#L279