OLD | NEW |
(Empty) | |
| 1 # Copyright (c) 2011 The Chromium Authors. All rights reserved. |
| 2 # Use of this source code is governed by a BSD-style license that can be |
| 3 # found in the LICENSE file. |
| 4 |
| 5 # libclosure (blocks) compatibilty for Mac OS X 10.5 (Leopard) |
| 6 # |
| 7 # Background material: |
| 8 # http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Blocks |
| 9 # http://opensource.apple.com/source/libclosure/libclosure-38/ |
| 10 # |
| 11 # Leopard doesn't support blocks. Chrome supports Leopard. Chrome needs to use |
| 12 # blocks. |
| 13 # |
| 14 # In any file where you use blocks (any time you type ^{...}), you must |
| 15 # #include block.h (in this directory) to ensure that the runtime symbols |
| 16 # used by libclosure are marked for weak-import. This means that if these |
| 17 # symbols are not present at runtime, the program will still load, but their |
| 18 # values will be NULL. |
| 19 # |
| 20 # In any target (in the GYP sense) where you use blocks, you must depend on |
| 21 # the closure_leopard_compat target (in this file) to ensure that these |
| 22 # symbols will be available at link time, even when the 10.5 SDK is in use. |
| 23 # This allows the continued use of the 10.5 SDK. |
| 24 # |
| 25 # This does not relieve you of the responsibility to not use blocks on |
| 26 # Leopard. Because runtime support for Blocks still isn't present on that |
| 27 # operating system, the weak-imported symbols will have value 0 and attempts |
| 28 # to do anything meaningful with them will fail or crash. You must take care |
| 29 # not to enter any block-using codepath on Leopard. The base::mac::IsOS* |
| 30 # family may be helpful. |
| 31 |
| 32 { |
| 33 'variables': { |
| 34 'chromium_code': 1, |
| 35 }, |
| 36 'targets': [ |
| 37 { |
| 38 'target_name': 'closure_leopard_compat', |
| 39 'conditions': [ |
| 40 ['mac_sdk == "10.5"', { |
| 41 'type': 'shared_library', |
| 42 'product_name': 'closure_leopard_compat_stub', |
| 43 'sources': [ |
| 44 'definitions.S', |
| 45 ], |
| 46 'xcode_settings': { |
| 47 # These values are taken from libSystem.dylib in the 10.5 SDK. |
| 48 # Setting LD_DYLIB_INSTALL_NAME causes anything linked against |
| 49 # this stub library to look for the symbols it provides in the |
| 50 # real libSystem at runtime. The real library's compatibility |
| 51 # version is used, and the value of the current version from the |
| 52 # SDK is used to make it appear as though anything linked against |
| 53 # this stub was linked against the real thing. |
| 54 'LD_DYLIB_INSTALL_NAME': '/usr/lib/libSystem.B.dylib', |
| 55 'DYLIB_COMPATIBILITY_VERSION': '1.0.0', |
| 56 'DYLIB_CURRENT_VERSION': '111.1.4', |
| 57 |
| 58 # Turn on stripping (yes, even in debug mode), and add the -c |
| 59 # flag. This is what produces a stub library (MH_DYLIB_STUB) as |
| 60 # opposed to a dylib (MH_DYLIB). MH_DYLIB_STUB files contain |
| 61 # symbol tables and everything else needed for linking, but are |
| 62 # stripped of section contents. This is the same way that the stub |
| 63 # libraries in Mac OS X SDKs are created. dyld will refuse to load |
| 64 # a stub library, so this provides some insurance in case anyone |
| 65 # tries to load the stub at runtime. |
| 66 'DEPLOYMENT_POSTPROCESSING': 'YES', |
| 67 'STRIP_STYLE': 'non-global', |
| 68 'STRIPFLAGS': '-c', |
| 69 }, |
| 70 }, { # else: mac_sdk != "10.5" |
| 71 # When using the 10.6 SDK or newer, the necessary definitions are |
| 72 # already present in libSystem.dylib. There is no need to provide a |
| 73 # stub dylib to provide these symbols at link time. This target is |
| 74 # still useful to cause those symbols to be treated as weak imports. |
| 75 'type': 'none', |
| 76 }], |
| 77 ], |
| 78 'direct_dependent_settings': { |
| 79 'include_dirs': [ |
| 80 'include', |
| 81 ], |
| 82 }, |
| 83 }, |
| 84 ], |
| 85 } |
OLD | NEW |