Move Leopard compatible block code to content/.

BUG=95573
TEST=no change

Review URL: http://codereview.chromium.org/8060022

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103017 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 62 insertions, 0 deletions

diff --git a/content/content.gyp b/content/content.gyp
index 20b8581..cdc8712 100644
--- a/content/content.gyp
+++ b/content/content.gyp
@@ -117,6 +117,68 @@
         ],
       },
      ],
+     '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',
+               }],
+             ],
+           },
+         ],
+       }],
+      ],
     },
     { # component != static_library
      'target_defaults': {