[chromium-reviews] Make the workaround from bug 43791 unconditional (issue2082002)

[ma...@chromium.org]

Reviewers: Yury Semikhatsky,

Message:
TBR (build break) following WebKit roll at r47143

Description:
Make the workaround from bug 43791 unconditional. When linking unit_tests on
the Mac, always give libwebcore.a to the linker first.

BUG=43791
TEST=unit_tests should link on Mac in debug mode

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=47147

Please review this at http://codereview.chromium.org/2082002/show

SVN Base: svn://svn.chromium.org/chrome/trunk/src/

Affected files:
M chrome/chrome_tests.gypi


Index: chrome/chrome_tests.gypi
===================================================================
--- chrome/chrome_tests.gypi (revision 47146)
+++ chrome/chrome_tests.gypi (working copy)
@@ -1136,39 +1136,26 @@
# other things like the ui, startup, and page_cycler tests.
*shrug*
'xcode_settings': {'OTHER_LDFLAGS': ['-Wl,-ObjC']},

- # The Mac Valgrind and Coverage builds use compilation
- # settings that cause their code size to swell more than any
- # other build. In particular, libwebcore.a is so large that
- # ld may not have a sufficiently large "hole" in its address
- # space into which it can be mmaped by the time it reaches
- # this library. As of May 10, 2010, libwebcore.a is 1023MB
- # in this build. In the Mac OS X 10.5 toolchain, using Xcode
- # 3.1, ld is only a 32-bit executable, and address space
+ # libwebcore.a is so large that ld may not have a sufficiently
large
+ # "hole" in its address space into which it can be mmaped by the
+ # time it reaches this library. As of May 10, 2010, libwebcore.a
is
+ # about 1GB in some builds. In the Mac OS X 10.5 toolchain, using
+ # Xcode 3.1, ld is only a 32-bit executable, and address space
# exhaustion is the result, with ld failing and producing
# the message:
# ld: in .../libwebcore.a, can't map file, errno=12
#
- # As a workaround, in these builds, ensure that libwebcore.a
- # appears to ld first when linking unit_tests. This allows
- # the library to be mmaped when ld's address space is "wide
- # open." Other libraries are small enough that they'll be
- # able to "squeeze" into the remaining holes. The Mac linker
- # isn't so sensitive that moving this library to the front
- # of the list will cause problems.
- 'variables': {
- # release_valgrind_build may not be defined at this point, so
- # provide a default definition here (matching the one in
- # build/common.gypi).
- 'release_valgrind_build%': 0,
- },
- 'conditions': [
- ['release_valgrind_build==1 or coverage==1', {
- # Enough pluses to make get this target prepended to the
- # target's list of dependencies.
- 'dependencies+++': [
- '../third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp:webcore',
- ],
- }],
+ # As a workaround, ensure that libwebcore.a appears to ld first
when
+ # linking unit_tests. This allows the library to be mmapped when
+ # ld's address space is "wide open." Other libraries are small
+ # enough that they'll be able to "squeeze" into the remaining
holes.
+ # The Mac linker isn't so sensitive that moving this library to
the
+ # front of the list will cause problems.
+ #
+ # Enough pluses to make get this target prepended to the target's
+ # list of dependencies.
+ 'dependencies+++': [
+ '../third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp:webcore',
],
}, { # OS != "mac"
'dependencies': [