Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[contrib][vcl] Fix VCL builds with GCC (#37075)
Commit Message: There were a few issues with building Envoy with VCL. The fist issue is that vppinfra library is built with LTO enabled. While there is nothing wrong with enabling LTO, it apparently triggers some bug in GCC - during linking one of the LTO passes just consumes all the memory in the system and eventually crashes without finishing ( I tried to build Envoy on a system with 256GiB of memory and it wasn't enough, so it's way past what is reasonable). To workaround the issue I updated vpp_vcl.patch to conditionally disable LTO when building using GCC. Once LTO was disabled I hit another issue - the order of libraries in linker command line does matter, at least in the world of Unix-like systems. Normally, Bazel can figure out the right order, but with VPP static libraries that are built by CMake Bazel has no information to figure out what is the proper order of those libraries. And that ultimately resulted in linking failures. I considered a few options to address the issue: 1. Use alwayslink = True - while it should be the simplest and the least surprising solution to the problem, apparently, alwayslink does not do anything for static libraries, so this option does not work 2. Maintain the right order of libraries in the BUILD file - that works, but it's unusual when order of targets in Bazel srcs and deps matters, so to avoid surprising behaviour I didn't go for that option 3. Use genrule and combine different static libraries into a single static library - it should work in theory, but I couldn't refer to the `ar` tool from genrule and abandoned this option 4. Use --start-group and --end-group linker options to tell to the linker that all VPP static libraries should be considered together as a single unit - this is the option I implemented in the end. Additional Description: This is part of the work done to fix gcc builds of Envoy tracked in #31807. This change by itself does not address the issue completely yet, but it moves us a bit closer. Signed-off-by: Mikhail Krinkin <[email protected]>
- Loading branch information