Weak-import more symbols in closure_blocks_leopard_compat

chrome/browser/mac/closure_blocks_leopard_compat.S

 # Copyright (c) 2011 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # Definitions of symbols that may be needed at runtime but aren't necessarily
 # present in the SDK chosen for compilation.
 #
 # This file provides symbols for _NSConcreteGlobalBlock and
 # _NSConcreteStackBlock, normally present in libSystem.dylib and provided by
-# by libclosure-38/data.c in Mac OS X 10.6 and later. When using the 10.5 SDK,
-# the symbols are not present. This file's definition can be used with extreme
-# care in an application that needs to use the 10.5 SDK in conjunction with
-# blocks.
+# by libclosure-38/data.c in Mac OS X 10.6 and later. It also provides symbols
+# for various block runtime functions provided by libclosure-38/runtime.c.
+# When using the 10.5 SDK, the symbols are not present. This file's definition
+# can be used with extreme care in an application that needs to use the 10.5
+# SDK in conjunction with blocks.
 #
 # This file cooperates with the build system to produce a dynamic library
 # that, when linked against, causes dependents to look in libSystem for the
 # symbols provided here. It also cooperates with a header that causes
 # dependents to treat the symbols provided here as weak imports, critical for
 # the resultant output to be loadable on 10.5.
 
 # To simplify things, this file assumes it's being built with the 10.5 SDK,
 # a deployment target of 10.5, and is producing 32-bit x86 code. Other
 # combinations are possible, but not interesting for the time being. See
 # <sys/cdefs.h> for interesting ways that names might be mangled in other
 # configurations.
 
 #include <AvailabilityMacros.h>
 
 #if MAC_OS_X_VERSION_MIN_REQUIRED != MAC_OS_X_VERSION_10_5 || \
     MAC_OS_X_VERSION_MAX_ALLOWED != MAC_OS_X_VERSION_10_5 || \
     !defined(__i386__)
 #error This file only supports 32-bit x86 code with both SDK and DT set to 10.5
 #endif
 
 #define DEFINE_GLOBAL_SYMBOL(name) \
     .globl name ## ;\
     name ## :
 
+.text
+
+# Mac OS X 10.6.8 libclosure-38/runtime.c
+
+DEFINE_GLOBAL_SYMBOL(__Block_copy)
+DEFINE_GLOBAL_SYMBOL(__Block_release)
+DEFINE_GLOBAL_SYMBOL(__Block_object_assign)
+DEFINE_GLOBAL_SYMBOL(__Block_object_dispose)
+
 .section __DATA,__data
 
+# Mac OS X 10.6.8 libclosure-38/data.c
+
 DEFINE_GLOBAL_SYMBOL(__NSConcreteGlobalBlock)
 DEFINE_GLOBAL_SYMBOL(__NSConcreteStackBlock)
 
 # When this file is in use, the linker is expected to link things against both
 # this file and the real copy of libSystem present in the SDK. When doing so,
 # the linker is smart enough to produce only one LC_LOAD_DYLIB load command.
 # However, it's not smart enough to notice that while this file's dylib only
 # provides weak-imported symbols, the real libSystem's dylib does not.
 # Consequently, it may produce an LC_LOAD_WEAK_DYLIB load command for
 # libSystem instead of an ordinary LC_LOAD_DYLIB command. LC_LOAD_WEAK_DYLIB
@@ skipping 67 matching lines @@
 
 # Some data-section symbols that might be referenced.
 
 .section __DATA,__data
 
 DEFINE_GLOBAL_SYMBOL(___stdinp)
 DEFINE_GLOBAL_SYMBOL(___stdoutp)
 DEFINE_GLOBAL_SYMBOL(___stderrp)
 
 #undef DEFINE_GLOBAL_SYMBOL