views:

36

answers:

2

I am trying to build an application in Xcode 3.2.4 and am getting the following linker error:

Undefined symbols:
  "___block_global_1", referenced from:
      ___block_holder_tmp_1.120 in foobarbaz.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I'm at a loss to explain what I've done in my source file that might be causing the error. I do have a block that I am defining as a global variable, like so:

typedef void(^error_block_t)(NSError* error);

error_block_t error_handler_s = ^void(NSError* error)
{
    //...
}

This block is defined in an empty namespace in the source (I'm compiling Objective-C++.) Everything compiles without error.

Update: Moving the block to be a local variable for the routine that references it is a viable (though not preferred) workaround.

What gives?

A: 

If the error_handler_s is not intended to be exported, you could make it static as another workaround.

namespace {
  ...
  static error_block_t error_handler_s = ^void(NSError* error) { ... };
  ...
}

Otherwise, I believe this is a bug in gcc.

KennyTM
@KennyTM: Thanks for the reply; if I'm reading 7.3.1.1(2) of the spec right it seems the unnamed-namespace paradigm I am using is preferred over declaring the variable `static`- since the former is intended to replace the latter, I can't see how this would help. If I am mistaken, please let me know.
fbrereto
@fbrereto: In theory, yes. However, in gcc, a non-`static` global variable in an anonymous namespace will still generate a symbol for the linker, while a `static` global variable will not. The standard doesn't always describe the real world correctly.
KennyTM
@KennyTM: You're certainly right about the standard v. the real world! I'll give your recommendation a shot; thanks.
fbrereto
@KennyTM: I just tried making the block `static` and no dice: the linker error is the same. Thanks for the try though.
fbrereto
A: 

At this point I believe this issue to be a bug.

fbrereto