diff options
| author | fischman@chromium.org <fischman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-07-29 23:35:39 +0000 |
|---|---|---|
| committer | fischman@chromium.org <fischman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-07-29 23:35:39 +0000 |
| commit | 6211f620d2068c21599633488f752555cb29054a (patch) | |
| tree | f15a9e9250a45a44d333b3fa9a8c4f46173180b9 /build/common.gypi | |
| parent | 34dc645193743944aac8cbf8bf7206a0257d302b (diff) | |
| download | chromium_src-6211f620d2068c21599633488f752555cb29054a.zip chromium_src-6211f620d2068c21599633488f752555cb29054a.tar.gz chromium_src-6211f620d2068c21599633488f752555cb29054a.tar.bz2 | |
build/common.gypi: revert the change to GCC_STRICT_ALIASING:NO because some bots have a too-old xcode.
In particular, rolling chromium_revision in webrtc from 211877 to 211878 broke
the webrtc mac Release bots:
http://build.chromium.org/p/client.webrtc/builders/Mac64%20Release/builds/296
http://build.chromium.org/p/client.webrtc/builders/Mac32%20Release/builds/312
http://build.chromium.org/p/client.webrtc/builders/Mac%20Asan/builds/304
The breakage did not repro on the webrtc trybots which use ninja (filed
https://code.google.com/p/webrtc/issues/detail?id=2135 to fix the inconsistency)
nor did it repro in an xcode build on my MBP (4.6.3). My theory is that the
xcode on the bots (e.g. vm674-m3) is too old (4.5.1).
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/20666002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214260 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build/common.gypi')
| -rw-r--r-- | build/common.gypi | 13 |
1 files changed, 10 insertions, 3 deletions
diff --git a/build/common.gypi b/build/common.gypi index 00ad653..d67c5f1 100644 --- a/build/common.gypi +++ b/build/common.gypi @@ -3984,9 +3984,16 @@ 'MACOSX_DEPLOYMENT_TARGET': '<(mac_deployment_target)', # Keep pch files below xcodebuild/. 'SHARED_PRECOMPS_DIR': '$(CONFIGURATION_BUILD_DIR)/SharedPrecompiledHeaders', - - # -fno-strict-aliasing, see http://crbug.com/32204 - 'GCC_STRICT_ALIASING': 'NO', + 'OTHER_CFLAGS': [ + # Someday this can be replaced by an 'GCC_STRICT_ALIASING': 'NO' + # xcode_setting, but not until all downstream projects' mac bots are + # using xcode >= 4.6, because that's when the default value of the + # flag in the compiler switched. Pre-4.6, the value 'NO' for that + # setting is a no-op as far as xcode is concerned, but the compiler + # behaves differently based on whether -fno-strict-aliasing is + # specified or not. + '-fno-strict-aliasing', # See http://crbug.com/32204. + ], }, 'target_conditions': [ ['_type=="executable"', { |