bazel/cc_configure.bzl breaks builds for C libraries #839
Comments
|
Which C libraries are these? I was assuming that we are only building C++ with this toolchain under Bazel, due to the fact that Envoy is pure C++. |
|
gRPC (c-core) |
|
Basically, Bazel is completely broken today and tries to build C++ files with |
|
Yes I understand. For now we can live without using cc_configure so it is not urgent, will do a PR if I have cycle. |
|
This is fixed now, using the wrapper script in #2631. |
Description: brings in an envoy update. Relevant commits:
- #11127 which uses the construct on first use idiom for certain static variables in the histogram code which were causing #688.
Risk Level: low
Testing: fixed local repro of the crash.
Fixes #688
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
Description: brings in an envoy update. Relevant commits:
- #11127 which uses the construct on first use idiom for certain static variables in the histogram code which were causing #688.
Risk Level: low
Testing: fixed local repro of the crash.
Fixes #688
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
We used to decommit (with MADV_FREE or MADV_DONTNEED) whole combined
span when freeing span in aggressive decommit mode. The issue with
that is preceding or following span with which we combined span we're
freeing could be freed already and fairly large. By passing all of
that memory to decommit, we force kernel to scan all of those pages.
When mass-freeing many objects old behavior led to O(N^2) behavior
since freeing single span could lead to MADV_{FREE,DONTNEED}-ing of
most of the heap.
New implementation just does decommit of individual bits as needed.
While there, I'm also adding locking to calls of
PageHeap::{Get,Set}AggressiveDecommit.
This partially (or mostly) fixes issue envoyproxy#839.
It forces use of
g++to even compile.cfiles, causes failure.@htuch
The text was updated successfully, but these errors were encountered: