Chromium Code Reviews| Index: base/base.gyp |
| =================================================================== |
| --- base/base.gyp (revision 124212) |
| +++ base/base.gyp (working copy) |
| @@ -166,6 +166,7 @@ |
| 'lazy_instance_unittest.cc', |
| 'linked_list_unittest.cc', |
| 'logging_unittest.cc', |
| + 'mac/closure_blocks_leopard_compat_unittest.cc', |
| 'mac/foundation_util_unittest.mm', |
| 'mac/mac_util_unittest.mm', |
| 'mac/objc_property_releaser_unittest.mm', |
| @@ -355,6 +356,11 @@ |
| 'win/win_util_unittest.cc', |
| ], |
| }], |
| + ['OS=="mac"', { |
| + 'dependencies': [ |
| + 'closure_blocks_leopard_compat', |
|
Mark Mentovai
2012/03/01 01:25:11
I'd rather just make the targets that need it depe
jam
2012/03/01 01:27:20
this is for base_unittests. won't that need it for
|
| + ], |
| + }], |
| ], |
| }, |
| { |
| @@ -463,7 +469,7 @@ |
| }, |
| ], |
| 'conditions': [ |
| - [ 'OS == "win"', { |
| + ['OS == "win"', { |
| 'targets': [ |
| { |
| 'target_name': 'debug_message', |
| @@ -479,5 +485,68 @@ |
| }, |
| ], |
| }], |
| + ['OS=="mac"', { |
| + 'targets': [ |
| + { |
| + 'target_name': 'closure_blocks_leopard_compat', |
| + 'sources': [ |
| + 'mac/closure_blocks_leopard_compat.h', |
| + ], |
| + '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': [ |
| + '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', |
| + }], |
| + ], |
| + }, |
| + ], |
| + }], |
| ], |
| } |