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
diff --git a/chrome/chrome_browser.gypi b/chrome/chrome_browser.gypi
index 86267c1..c06f6279 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',
- }],
- ],
- },
- ],
- }],
- ],
}
