mac: In component builds, link against libc++.

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 5268 matching lines @@
           '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.
           ],
+          'conditions': [
+            ['component=="shared_library"', {
+              # In component builds, link to the system libc++. This requires
+              # OS X 10.7, but we currently pass -mmacosx-version-min=10.6.
+              # Xcode's clang complains about this, but our open-source bundled
+              # chromium clang doesn't -- it just doesn't implicitly add -lc++
+              # either.  Explicitly add that flag.  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': [
+                ['_type!="static_library"', {
+                  # OTHER_LDFLAGS is passed to both .so and .a links, but only
+                  # the former type understands it.  Hence the _type check.
+                  'OTHER_LDFLAGS': [ '-lc++' ],

[Mark Mentovai, 2015/10/16 22:34:59]

I thought CLANG_CXX_LIBRARY would have been enough. Is it not? What does the
link line look like now? I don’t want to wind up with something like -lc++
-lstdc++.

[Nico, 2015/10/16 23:08:35]

Excellent question! I thought it wasn't enough because we pass
-mmin-macosx-version=10.6, but it turns out I screwed up my local testing and
this isn't needed. Done.

+                }],
+              ]
+            }],
+          ],
         },
         'target_conditions': [
           ['_type=="executable"', {
             'postbuilds': [
               {
                 # Arranges for data (heap) pages to be protected against
                 # code execution when running on Mac OS X 10.7 ("Lion"), and
                 # ensures that the position-independent executable (PIE) bit
                 # is set for ASLR when running on Mac OS X 10.5 ("Leopard").
                 'variables': {
@@ skipping 998 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }