build: remove cc_configure and cc_wrapper

[lizan]

Signed-off-by: Lizan Zhou lizan@tetrate.io

Description:
Use BAZEL_LINKLIBS to statically link libstdc++ and libc++, get rid of cc_wrapper. Requires Bazel >= 0.28. Additional compiler options which was in cc_wrapeer moved into envoy_copts with select.

Side effect: static linking libstdc++ applies to all binaries built with the toolchain, so tests are now statically linked with libstdc++.

Risk Level: Med, affecting depending projects
Testing: CI
Docs Changes: N/A
Release Notes: N/A

[jmillikin-stripe]

What effect does this have on macOS or Windows builds? Is there any way to set it only on Linux?

[lizan]

From my read of https://github.com/bazelbuild/bazel/tree/0.28.0/tools/cpp this env doesn't have any effect on configure_osx_toolchain or configure_windows_toolchain so it should be no-op.

[jmillikin-stripe]

LGTM

[htuch]

In principle, this PR is really great, it will hugely simplify build. One downside is we lose an interception point to workaround Bazel issues, but I guess we can always introduce it again later. Beyond libc++ handling, it looks like this line is something that we were using cc_wrapper for previously, what happens to this?

[lizan]

In my TODO above:

migrate compiler options to envoy_copts with select

will update for this and make it ready for review.

[lizan]

@htuch this is ready to review, PTAL again

[htuch]

How did test behavior change in the PR? I thought we were just removing wrappers.

[lizan]

This changes how we link libstdc++ in tests, previously, libstdc++ is dynamically linked for tests as envoy_static_link_libstdcpp_linkopts isn't added to envoy_cc_test linkopts. With this PR tests are linked with libstdc++ too so the number changed. Current master with following patch produces same number:

diff --git a/bazel/envoy_test.bzl b/bazel/envoy_test.bzl
index ea564d619..c502fa007 100644
--- a/bazel/envoy_test.bzl
+++ b/bazel/envoy_test.bzl
@@ -150,7 +150,7 @@ def envoy_cc_test(
     native.cc_test(
         name = name,
         copts = envoy_copts(repository, test = True) + copts,
-        linkopts = _envoy_test_linkopts(),
+        linkopts = _envoy_test_linkopts() + envoy_static_link_libstdcpp_linkopts(),
         linkstatic = envoy_linkstatic(),
         malloc = tcmalloc_external_dep(repository),
         deps = [

[htuch]

Do we need to do this at the same time as this PR? If so, please update the top-level GH comment so we can also explain that this is happening.

[lizan]

Yes because BAZEL_LINKLIBS is toolchain configuration so applies to all binary. Updated description.

[htuch]

Thanks!

[PiotrSikora]

This seems to break foreign_cc C++ targets (e.g. llvm in envoyproxy/envoy-wasm), e.g.

Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS_WITHOUT_LIB failed with the following output:
Change Dir: /tmp/tmp.IkzQVESUR0/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/ninja cmTC_61032
[1/2] Building CXX object CMakeFiles/cmTC_61032.dir/src.cxx.o
[2/2] Linking CXX executable cmTC_61032
FAILED: cmTC_61032
: && /usr/lib/llvm-8/bin/clang  -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -std=c++0x -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted" -UDEBUG -DHAVE_CXX_ATOMICS_WITHOUT_LIB  -Werror=unguarded-availability-new -std=c++11  -fuse-ld=gold -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/lib/llvm-8/bin -lm -static-libgcc -l:libstdc++.a CMakeFiles/cmTC_61032.dir/src.cxx.o  -o cmTC_61032  -lm && :
CMakeFiles/cmTC_61032.dir/src.cxx.o:src.cxx:function __clang_call_terminate: error: undefined reference to '__cxa_begin_catch'
CMakeFiles/cmTC_61032.dir/src.cxx.o:src.cxx:function __clang_call_terminate: error: undefined reference to 'std::terminate()'
CMakeFiles/cmTC_61032.dir/src.cxx.o(.eh_frame+0x12b): error: undefined reference to '__gxx_personality_v0'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Source file was:

#include <atomic>
std::atomic<int> x;
int main() {
  return x;
}

There might be some other silent failures, due to optional features that can no longer be detected.

@lizan any ideas?

[lizan]

@PiotrSikora hmm, not sure why #7329 didn't break this, cc_wrapper -std=c++11 atomic.cc broke too. This patch seems work, you're only using static libraries from LLVM so should be no-op to that:

diff --git a/bazel/foreign_cc/BUILD b/bazel/foreign_cc/BUILD
index e031e6a1c..d010a34f0 100644
--- a/bazel/foreign_cc/BUILD
+++ b/bazel/foreign_cc/BUILD
@@ -142,6 +142,7 @@ envoy_cmake_external(
         "LLVM_ENABLE_ZLIB": "off",
         "LLVM_TARGETS_TO_BUILD": "X86",
         "CMAKE_BUILD_TYPE": "RelWithDebInfo",
+        "CMAKE_CXX_FLAGS": "-lstdc++",
     },
     env_vars = {
         # Workaround for the -DDEBUG flag added in fastbuild on macOS,