Allow use of ^blocks, even with the 10.5 SDK, and even with a 10.5 runtime

chrome/browser/mac/closure_leopard_compat/block.h

+// 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.
+
+#ifndef CHROME_BROWSER_MAC_CLOSURE_LEOPARD_COMPAT_BLOCK_H_
+#define CHROME_BROWSER_MAC_CLOSURE_LEOPARD_COMPAT_BLOCK_H_
+#pragma once
+
+// __NSConcreteGlobalBlock is a private implementation detail of libclosure
+// defined in libclosure/libclosure-38/Block_private.h, but it's exposed from
+// libSystem as a public symbol, and the block-enabled compiler will emit code
+// that references this symbol. Because the symbol is not present in 10.5's
+// libSystem, it must be declared as a weak import in any file that uses
+// blocks. Any block-using file must #include this header to guarantee that
+// the symbol will show up in linked output as a weak import when compiling
+// for a 10.5 deployment target. Because the symbol is always present in 10.6
+// and higher, it does not need to be a weak import when the deployment target
+// is at least 10.6.
+
+#include <AvailabilityMacros.h>
+
+#if MAC_OS_X_VERSION_MIN_REQUIRED <= MAC_OS_X_VERSION_10_5  // DT <= 10.5
+
+extern "C" {
+
+__attribute__((weak_import)) extern void* _NSConcreteGlobalBlock[32];

[Mark Mentovai, 2011/08/08 18:30:21]

Nico: FYI: References to _NSConcreteGlobalBlock are compiler-emitted and don’t
really have anything to do with the declaration, and indeed, there is normally
no declaration in standard cases. This trick here is sufficient to get gcc-4.2
to treat it as a weak import, but it’s possible that clang behaves differently.
In that case, we’ll need to either fix clang or emit our own .weak_reference
directive in an asm block instead of doing this declaration with the weak_import
attribute.

+
+}  // extern "C"
+
+#endif  // DT <= 10.5
+
+#endif  // CHROME_BROWSER_MAC_CLOSURE_LEOPARD_COMPAT_BLOCK_H_