Move Leopard compatible block code to content/.

chrome/chrome_browser.gypi

Index: chrome/chrome_browser.gypi
diff --git a/chrome/chrome_browser.gypi b/chrome/chrome_browser.gypi
index 86267c1a2feaf540c05f3b9fdff8ad93c750c636..c06f62797fdef4e1575b310a70a144fce93dd6d8 100644
--- a/chrome/chrome_browser.gypi
+++ b/chrome/chrome_browser.gypi
@@ -4298,7 +4298,7 @@
             ],
           },
           'dependencies': [
-            'closure_blocks_leopard_compat',
+            '../content/content.gyp:closure_blocks_leopard_compat',
           ],
           'actions': [
             {
@@ -5025,65 +5025,4 @@
       'includes': [ '../build/protoc.gypi' ]
     },
   ],
-  'conditions': [
-    ['OS=="mac"', {
-      'targets': [
-        {
-          'target_name': 'closure_blocks_leopard_compat',
-          'conditions': [
-            ['mac_sdk == "10.5"', {
-              'type': 'shared_library',
-              'product_name': 'closure_blocks_leopard_compat_stub',
-              'variables': {
-                # This target controls stripping directly. See below.
-                'mac_strip': 0,
-              },
-              'sources': [
-                'browser/mac/closure_blocks_leopard_compat.S',
-              ],
-              'xcode_settings': {
-                # These values are taken from libSystem.dylib in the 10.5 SDK.
-                # Setting LD_DYLIB_INSTALL_NAME causes anything linked against
-                # this stub library to look for the symbols it provides in the
-                # real libSystem at runtime. When using ld from Xcode 4 or
-                # later (ld64-123.2 and up), giving two libraries with the
-                # same "install name" to the linker will cause it to print
-                # "ld: warning: dylibs with same install name". This is
-                # harmless, and ld will behave as intended here.
-                #
-                # The real library's compatibility version is used, and the
-                # value of the current version from the SDK is used to make
-                # it appear as though anything linked against this stub was
-                # linked against the real thing.
-                'LD_DYLIB_INSTALL_NAME': '/usr/lib/libSystem.B.dylib',
-                'DYLIB_COMPATIBILITY_VERSION': '1.0.0',
-                'DYLIB_CURRENT_VERSION': '111.1.4',
-
-                # Turn on stripping (yes, even in debug mode), and add the -c
-                # flag. This is what produces a stub library (MH_DYLIB_STUB)
-                # as opposed to a dylib (MH_DYLIB). MH_DYLIB_STUB files
-                # contain symbol tables and everything else needed for
-                # linking, but are stripped of section contents. This is the
-                # same way that the stub libraries in Mac OS X SDKs are
-                # created. dyld will refuse to load a stub library, so this
-                # provides some insurance in case anyone tries to load the
-                # stub at runtime.
-                'DEPLOYMENT_POSTPROCESSING': 'YES',
-                'STRIP_STYLE': 'non-global',
-                'STRIPFLAGS': '-c',
-              },
-            }, {  # else: mac_sdk != "10.5"
-              # When using the 10.6 SDK or newer, the necessary definitions
-              # are already present in libSystem.dylib. There is no need to
-              # build a stub dylib to provide these symbols at link time. This
-              # target is still useful to cause those symbols to be treated as
-              # weak imports in dependents, who still must #include
-              # closure_blocks_leopard_compat.h to get weak imports.
-              'type': 'none',
-            }],
-          ],
-        },
-      ],
-    }],
-  ],
 }