Re-enable stripping to produce an MH_DYLIB_STUB for

closure_blocks_leopard_compat_stub.

This was originally checked in at r95892, but the stripping was disabled in
r95895 because the original implementation resulted in a double-strip, and
you can't strip something again once it's been turned into an MH_DYLIB_STUB.

BUG=91978
TEST=Builds remain green
Review URL: http://codereview.chromium.org/7598037

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

chrome/browser/mac/closure_blocks_leopard_compat.S

@@ -5,18 +5,18 @@
 # Definitions of symbols that may be needed at runtime but aren't necessarily
 # present in the SDK chosen for compilation.
 #
-# This file provides a symbols for _NSConcreteGlobalBlock and
+# 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 symbol is not present. This file's definition can be used with extreme
+# 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 (closure_leopard_compat.gyp) 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 (block.h) that causes dependents to treat the symbols provided here
-# as weak imports, critical for the resultant output to be loadable on 10.5.
+# 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

chrome/browser/mac/closure_blocks_leopard_compat.h

@@ -24,7 +24,7 @@
 // In any target (in the GYP sense) where you use blocks, you must also depend
 // on the closure_blocks_leopard_compat target to ensure that these symbols
 // will be available at link time, even when the 10.5 SDK is in use. This
-// This allows the continued use of the 10.5 SDK, which does not contain these
+// allows the continued use of the 10.5 SDK, which does not contain these
 // symbols.
 //
 // This does not relieve you of the responsibility to not use blocks on
@@ -40,17 +40,16 @@
 // qualifies, as do sufficiently recent versions of clang. GCC 4.2 as shipped
 // with Xcode 3.1 for Mac OS X 10.5 does not qualify.
 
-// _NSConcreteGlobalBlock and _NSConcreteStackBlock are a private
-// implementation details of libclosure defined in
-// libclosure/libclosure-38/Block_private.h, but they're exposed from
-// libSystem as public symbols, and the block-enabled compiler will emit code
-// that references these symbols. Because the symbols aren't present in 10.5's
-// libSystem, they must be declared as weak imports in any file that uses
-// blocks. Any block-using file must #include this header to guarantee that
-// the symbols will show up in linked output as weak imports when compiling
-// for a 10.5 deployment target. Because the symbols are always present in
-// 10.6 and higher, they do not need to be a weak imports when the deployment
-// target is at least 10.6.
+// _NSConcreteGlobalBlock and _NSConcreteStackBlock are private implementation
+// details of libclosure defined in libclosure/libclosure-38/Block_private.h,
+// but they're exposed from libSystem as public symbols, and the block-enabled
+// compiler will emit code that references these symbols. Because the symbols
+// aren't present in 10.5's libSystem, they must be declared as weak imports
+// in any file that uses blocks. Any block-using file must #include this
+// header to guarantee that the symbols will show up in linked output as weak
+// imports when compiling for a 10.5 deployment target. Because the symbols
+// are always present in 10.6 and higher, they do not need to be a weak
+// imports when the deployment target is at least 10.6.
 //
 // Both GCC and clang emit references to these symbols, providing implicit
 // declarations as needed, but respecting any user declaration when present.

chrome/chrome_browser.gypi

@@ -4917,6 +4917,10 @@
             ['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',
               ],
@@ -4924,13 +4928,32 @@
                 # 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. 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.
+                # 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