mac: In static library builds, link against a static libc++.a

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 5238 matching lines @@
                     # grown larger than 4GB, which dsymutil can't handle. Reduce
                     # the amount of debug symbols.
                     '-fno-standalone-debug',  # See http://crbug.com/479841
                   ]
                 },
               }],
             ],
           },  # configuration "Release"
         },  # configurations
         'xcode_settings': {
+          # 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)

[Mark Mentovai, 2015/10/23 13:56:36]

Is this a local change that we’ve made to clang, or is the error a local change
that Apple has made in their own version?

[Nico, 2015/10/23 15:39:29]

That's a local change Apple has in their branch. We don't have any local changes
in our clang, it's pure upstream. Apple did upstream their change long ago in
http://llvm.org/viewvc/llvm-project?rev=141374&view=rev but people complained
that that broke their libc++ + 10.6 experiments, so they reverted it again
http://llvm.org/viewvc/llvm-project?rev=141566&view=rev and now they're carrying
that as a downstream diff.

+          # 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 again /usr/lib/libc++.dylib when it sees

[Mark Mentovai, 2015/10/23 13:56:36]

again → against

[Nico, 2015/10/23 15:39:29]

Done.

+          #    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)
           # MACOSX_DEPLOYMENT_TARGET maps to -mmacosx-version-min
           'MACOSX_DEPLOYMENT_TARGET': '<(mac_deployment_target)',
           # Keep pch files below xcodebuild/.
           'SHARED_PRECOMPS_DIR': '$(CONFIGURATION_BUILD_DIR)/SharedPrecompiledHeaders',
           '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.  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 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.
+            'library_dirs': [
+              '<(DEPTH)/third_party/libc++-static',

[Nico, 2015/10/23 13:05:33]

The alternative here would be to use clang instead of clang++ to link our c++
code and then add the -lc++-static flag ourselves. We still need this -L flag
then, but it's maybe a bit less surprising. In gyp, this would be possible with
some gyp changes (currently, ldxx can't be overwritten) but gn hardcodes clang++
as linker, even for targets with C files only. This approach works without
needing changes in both gyp and gn.

[Mark Mentovai, 2015/10/23 13:56:36]

Nico (vacation Fri Oct 23) wrote:
I think I slightly prefer what you’ve done here.

+            ],
+          }],
           ['_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': {
                   # Define change_mach_o_flags in a variable ending in _path
                   # so that GYP understands it's a path and performs proper
@@ skipping 995 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',
   },
 }