Split browser.lib to avoid hitting 4 GB limit
In some build configurations on Windows (official build, goma with
symbol_level = 2) browser.lib can grow to about 4 GB which leads to
cryptic build failures. Rather than trying to carefully calculate which
configurations need to split browser.lib it is simpler to just always
split it on Windows. There is no real 'cost' for doing this other than
some potential confusion when developers look at the build internals.
Instead of building obj\chrome\browser\browser.lib the files built will
be obj\chrome\browser\browser_?.lib where '?' is 0-4.
BUG=701862
Review-Url: https://codereview.chromium.org/2767693002
Cr-Commit-Position: refs/heads/master@{#458961}
diff --git a/chrome/browser/BUILD.gn b/chrome/browser/BUILD.gn
index a22a313..1618ea9 100644
--- a/chrome/browser/BUILD.gn
+++ b/chrome/browser/BUILD.gn
@@ -55,9 +55,11 @@
# Use a static library here because many test binaries depend on this but don't
# require many files from it. This makes linking more efficient.
split_static_library("browser") {
- # Split into multiple static libraries on Windows official builds, where we
- # run into a 2GB max size limit.
- if (is_win && is_official_build) {
+ # Split into multiple static libraries on Windows builds. We have hit size
+ # on Windows official builds and on goma builds symbol_level = 2 is selected.
+ # Always splitting on Windows builds is simpler than trying to perfectly
+ # calculate the scenarios where it is required.
+ if (is_win) {
split_count = 5
} else {
split_count = 1
