Trying blocks
I am trying to implement a block in one of my apps. The code looks
like this...
BOOL (^fillWindow)(void) = ^(void) {
BOOL empty = YES;
int s = 0;
for (NSTextField *theTextField in textFieldArray) {
int textFieldValue = [[theTextField stringValue]
intValue];
empty = empty (textFieldValue == 0);
[thePuzzle replaceObjectAtIndex: s++ withObject: [NSNumber
numberWithInt: sudokuTextFieldValue]];
}
return empty;
};
if (!fillWindow()) {...
It compiles fine but the load fails with...
__NSConcreteGlobalBlock, referenced from:
___block_holder_tmp_1.1207 in Controller.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Can anyone explain this and help me with what I'm not doing or not
doing right?
Charlie Dickman
3tothe...@comcast.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trying blocks
On Oct 28, 2009, at 5:56 PM, Charlie Dickman wrote: It compiles fine but the load fails with... __NSConcreteGlobalBlock, referenced from: ___block_holder_tmp_1.1207 in Controller.o ld: symbol(s) not found collect2: ld returned 1 exit status Can anyone explain this and help me with what I'm not doing or not doing right? Blocks are only available on Mac OS X 10.6. Make sure your project's SDK is set to 10.6 (or alternatively Current Mac OS if you're compiling on a 10.6 machine). Blocks are currently unsupported on Mac OS X 10.5 and iPhone OS. _NSConcreteGlobalBlock comes from CoreFoundation. You could get this error if you weren't liking to CoreFoundation, but presumably you are linking to CoreFoundation by way of Cocoa.framework. (Otherwise you'd have trouble with NSNumber and NSTextField too.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying blocks
Le 30 oct. 2009 à 07:33, Greg Parker a écrit : On Oct 28, 2009, at 5:56 PM, Charlie Dickman wrote: It compiles fine but the load fails with... __NSConcreteGlobalBlock, referenced from: ___block_holder_tmp_1.1207 in Controller.o ld: symbol(s) not found collect2: ld returned 1 exit status Can anyone explain this and help me with what I'm not doing or not doing right? Blocks are only available on Mac OS X 10.6. Make sure your project's SDK is set to 10.6 (or alternatively Current Mac OS if you're compiling on a 10.6 machine). Blocks are currently unsupported on Mac OS X 10.5 and iPhone OS. _NSConcreteGlobalBlock comes from CoreFoundation. You could get this error if you weren't liking to CoreFoundation, but presumably you are linking to CoreFoundation by way of Cocoa.framework. (Otherwise you'd have trouble with NSNumber and NSTextField too.) I hate having to contradict you, but according to nm, all block runtime symbols are in libSystem (although CoreFoundation probably override them at runtime to use its own classes). nm -m CoreFoundation (undefined) external __NSConcreteAutoBlock (from libSystem) (undefined) external __NSConcreteFinalizingBlock (from libSystem) (undefined) external __NSConcreteGlobalBlock (from libSystem) (undefined) external __NSConcreteMallocBlock (from libSystem) (undefined) external __NSConcreteStackBlock (from libSystem) (undefined) external __NSConcreteWeakBlockVariable (from libSystem) -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying blocks
On Oct 28, 2009, at 8:56 PM, Charlie Dickman wrote: It compiles fine but the load fails with... __NSConcreteGlobalBlock, referenced from: ___block_holder_tmp_1.1207 in Controller.o ld: symbol(s) not found collect2: ld returned 1 exit status Can anyone explain this and help me with what I'm not doing or not doing right? I started a thread about this on the xcode-users list a day or two ago. As far as I have been able to determine, you cannot include blocks- based code in a binary that runs on Leopard or older as well as on Snow Leopard. Testing for Leopard and older and branching around the blocks code does not solve the problem, because the linker still expects to see the blocks symbols at load time and they aren't there on Leopard and older. One solution, therefore, is to limit your application to Snow Leopard and give up on Leopard. Apparently, one way to make your application work on older systems, as well, is to create two binaries using one of the techniques described in Technical Note TN2064: Ensuring Backwards Binary Compatibility - Weak Linking and Availability Macros on Mac OS X. A gross way to do this is to build one target for Snow Leopard and a separate target for Leopard and older, using availability macros so that the blocks-based code doesn't even compile into the Leopard-and-older binary. But then you have the problem of distributing two versions of your application, or writing a load-time helper that figures out which binary to load at run time. Alternatively, you could isolate the blocks-based calls in a small separate bundle in your application package and load it at run time if you're running on Snow Leopard. Does anybody have any better solutions? Working code? -- Bill Cheeseman b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying blocks
On Oct 30, 2009, at 1:40 AM, Jean-Daniel Dupas wrote: Le 30 oct. 2009 à 07:33, Greg Parker a écrit : On Oct 28, 2009, at 5:56 PM, Charlie Dickman wrote: It compiles fine but the load fails with... __NSConcreteGlobalBlock, referenced from: ___block_holder_tmp_1.1207 in Controller.o ld: symbol(s) not found collect2: ld returned 1 exit status Can anyone explain this and help me with what I'm not doing or not doing right? Blocks are only available on Mac OS X 10.6. Make sure your project's SDK is set to 10.6 (or alternatively Current Mac OS if you're compiling on a 10.6 machine). Blocks are currently unsupported on Mac OS X 10.5 and iPhone OS. _NSConcreteGlobalBlock comes from CoreFoundation. You could get this error if you weren't liking to CoreFoundation, but presumably you are linking to CoreFoundation by way of Cocoa.framework. (Otherwise you'd have trouble with NSNumber and NSTextField too.) I hate having to contradict you, but according to nm, all block runtime symbols are in libSystem (although CoreFoundation probably override them at runtime to use its own classes). My mistake. The symbol _NSConcreteGlobalBlock is in libSystem, which is what the linker above is looking for. The actual implementation of the class _NSConcreteGlobalBlock is in CoreFoundation, which uses some extra magic to tie the symbol and the class together at runtime. This is all part of the twisty maze to make blocks work in CF-less C code, while also acting like Objective-C objects in Objective-C code. In any case, Charlie's linker error is unlikely to be a missing framework, since his code would not have gotten far without libc and CoreFoundation. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying blocks
On Oct 30, 2009, at 3:08 AM, Bill Cheeseman wrote: As far as I have been able to determine, you cannot include blocks- based code in a binary that runs on Leopard or older as well as on Snow Leopard. Testing for Leopard and older and branching around the blocks code does not solve the problem, because the linker still expects to see the blocks symbols at load time and they aren't there on Leopard and older. Is there a way that you could mark the block-related symbols as weak imports at link-time? Also, there is an open-source implementation of blocks for 10.5, including a compatible copy of the Clang compiler. I don't recall the name/URL of the package but it shouldn't be hard to find with some searching. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trying blocks
PLBlocks - http://code.google.com/p/plblocks/ Dave On Oct 30, 2009, at 9:28 AM, Jens Alfke wrote: Also, there is an open-source implementation of blocks for 10.5, including a compatible copy of the Clang compiler. I don't recall the name/URL of the package but it shouldn't be hard to find with some searching. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
