Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: remove cc_configure and cc_wrapper #7555

Merged
merged 8 commits into from
Jul 16, 2019
Merged

Conversation

lizan
Copy link
Member

@lizan lizan commented Jul 12, 2019

Signed-off-by: Lizan Zhou [email protected]

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

@@ -8,6 +8,8 @@ startup --host_jvm_args=-Xmx512m
build --workspace_status_command=bazel/get_workspace_status
build --experimental_remap_main_repo
build --host_force_python=PY2
build --action_env=BAZEL_LINKLIBS=-l%:libstdc++.a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Signed-off-by: Lizan Zhou <[email protected]>
Signed-off-by: Lizan Zhou <[email protected]>
Copy link
Contributor

@jmillikin-stripe jmillikin-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Signed-off-by: Lizan Zhou <[email protected]>
# it in clang builds causes a build error because of unknown command line
# flag.
# See https://github.com/envoyproxy/envoy/issues/2987
argv.append("-Wno-maybe-uninitialized")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my TODO above:

migrate compiler options to envoy_copts with select

will update for this and make it ready for review.

@lizan lizan marked this pull request as ready for review July 15, 2019 23:11
@lizan
Copy link
Member Author

lizan commented Jul 15, 2019

@htuch this is ready to review, PTAL again

@@ -210,6 +210,7 @@ TEST_P(ClusterMemoryTestRunner, MemoryLargeClusterSizeWithStats) {
// 2019/06/29 7364 45685 46000 combine 2 levels of stat ref-counting into 1
// 2019/06/30 7428 42742 43000 remove stats multiple inheritance, inline HeapStatData
// 2019/07/06 7477 42742 43000 fork gauge representation to drop pending_increment_
// 2019/07/15 7555 42806 43000 static link libstdc++ in tests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 = [

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Signed-off-by: Lizan Zhou <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@htuch htuch merged commit 14dd85d into envoyproxy:master Jul 16, 2019
@lizan lizan deleted the no_wrapper branch July 16, 2019 20:04
@PiotrSikora
Copy link
Contributor

PiotrSikora commented Jul 17, 2019

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
Copy link
Member Author

lizan commented Jul 17, 2019

@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,

lizan added a commit to lizan/envoy-filter-example that referenced this pull request Jul 17, 2019
lizan added a commit to envoyproxy/envoy-filter-example that referenced this pull request Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants