mac: Remove libc++ hack that was required by NaCl.

NaCl target were still built with the 10.6 SDK even after we thought we
switched the whole build to the 10.10 SDK. This was a problem in static
library ASan builds: -fsanitize=address implicitly requires libc++, so
this added a -lc++ to the link, but the 10.6 SDK doesn't contain a libc++
(since ASan requires 10.7, and since it also adds an implicit -lc++abi,
we dynamically link libc++ in ASan builds). This led to linker errors.

Now that NaCl targets build with the 10.10 SDK like everything else when
they're part of a Chromium build, the hack I used to work around this is
no longer needed, so remove it.

No intended behavior change.

BUG=400091

Review URL: https://codereview.chromium.org/1414703004

Cr-Commit-Position: refs/heads/master@{#356325}

1 files changed, 21 insertions, 43 deletions

diff --git a/build/common.gypi b/build/common.gypi
index 56dc197..5b05435 100644
--- a/build/common.gypi
+++ b/build/common.gypi
@@ -5260,15 +5260,27 @@
           },  # configuration "Release"
         },  # configurations
         'xcode_settings': {
-          # Everything should include libc++ headers. Just passing
-          # -stdlib=libc++ doesn't just work in NaCl targets with asan enabled
-          # until http://crbug.com/544325 is fixed, so tell the compiler to not
-          # add any include paths, and instead below add the c++ include
-          # directory as include_dirs.  Then we can not set CLANG_CXX_LIBRARY
-          # to libc++ for NaCl targets and that way they'll link against
-          # libstdc++ on the ASan bots (ASan requires a C++ library to be linked
-          # even for the C-only NaCl programs).
-          'OTHER_CPLUSPLUSFLAGS': [ '$inherited', '-nostdinc++', ],
+          # Tell the compiler to use libc++'s headers and the linker to link
+          # against libc++.  The latter part normally requires OS X 10.7,
+          # but we still support running on 10.6.  How does this work?  Two
+          # parts:
+          # 1. Chromium's clang doesn't error on -mmacosx-version-min=10.6
+          #    combined with -stdlib=libc++ (it normally silently produced a
+          #    binary that doesn't run on 10.6)
+          # 2. Further down, library_dirs is set to
+          #    third_party/libc++-static, which contains a static
+          #    libc++.a library.  The linker then links against that instead
+          #    of against /usr/lib/libc++.dylib when it sees the -lc++ flag
+          #    added by the driver.
+          #
+          # In component builds, just link to the system libc++.  This has
+          # the effect of making everything depend on libc++, which means
+          # component-build binaries won't run on 10.6 (no libc++ there),
+          # but for a developer-only configuration that's ok.  (We don't
+          # want to raise the deployment target yet so that official and
+          # dev builds have the same deployment target.  This affects
+          # things like which functions are considered deprecated.)
+          'CLANG_CXX_LIBRARY': 'libc++',  # -stdlib=libc++
 
           'GCC_DYNAMIC_NO_PIC': 'NO',               # No -mdynamic-no-pic
                                                     # (Equivalent to -fPIC)
@@ -5286,42 +5298,8 @@
             # specified or not.
             '-fno-strict-aliasing',  # See http://crbug.com/32204.
           ],
-          'conditions': [
-            # TODO(thakis): Remove this condition once http://crbug.com/544325
-            # is fixed. Some targets below native_client still link use the
-            # 10.6 SDK which doesn't contain a libc++.
-            ['mac_sdk!="10.6"', {
-              # Tell the compiler to use libc++'s headers and the linker to link
-              # against libc++.  The latter part normally requires OS X 10.7,
-              # but we still support running on 10.6.  How does this work?  Two
-              # parts:
-              # 1. Chromium's clang doesn't error on -mmacosx-version-min=10.6
-              #    combined with -stdlib=libc++ (it normally silently produced a
-              #    binary that doesn't run on 10.6)
-              # 2. Further down, library_dirs is set to
-              #    third_party/libc++-static, which contains a static
-              #    libc++.a library.  The linker then links against that instead
-              #    of against /usr/lib/libc++.dylib when it sees the -lc++ flag
-              #    added by the driver.
-              #
-              # In component builds, just link to the system libc++.  This has
-              # the effect of making everything depend on libc++, which means
-              # component-build binaries won't run on 10.6 (no libc++ there),
-              # but for a developer-only configuration that's ok.  (We don't
-              # want to raise the deployment target yet so that official and
-              # dev builds have the same deployment target.  This affects
-              # things like which functions are considered deprecated.)
-              'CLANG_CXX_LIBRARY': 'libc++',  # -stdlib=libc++
-
-            }],
-          ],
         },
         'target_conditions': [
-          ['>(nacl_untrusted_build)==0', {
-            'include_dirs': [
-              '<(DEPTH)/third_party/llvm-build/Release+Asserts/include/c++/v1',
-            ],
-          }],
           ['>(nacl_untrusted_build)==0 and component=="static_library"', {
             # See the comment for CLANG_CXX_LIBRARY above for what this does.
             # The NaCl toolchains have their own toolchain and don't need this.