46

I'm running Xcode 3.2.3 with the iOS 4.0 SDK. I built my app with Base SDK = iphoneos4.0, Active SDK = iphoneos4.0, Deployment Target = 3.1.3, and Architecture = standard (arm6 arm7). Compiler = GCC 4.2. As I understand it, this is the correct way to build an app for both iOS 4 and 3.

The app runs fine on devices running iOS 4. But it crashes on startup when you try to run it on a device with iOS 3.1.3 (an iPod Touch 1G):

dyld: Symbol not found: __NSConcreteStackBlock
  Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
  Expected in: /usr/lib/libSystem.B.dylib

It appears to be an issue with a fairly "low level" dynamically-linked library, BEFORE my main() function even gets called. I have even tried re-starting the device, etc., with no luck. Here's part of the the crash log:

Process:         MyApp [60]
Path:            /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Identifier:      MyApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2010-07-22 17:16:17.942 -0400
OS Version:      iPhone OS 3.1.3 (7E18)
Report Version:  104

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x00000001, 0xe7ffdefe
Crashed Thread:  0

Dyld Error Message:
  Symbol not found: __NSConcreteStackBlock
  Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
  Expected in: /usr/lib/libSystem.B.dylib
  Dyld Version: 149

Binary Images:
    0x1000 -    0x80fff +MyApp armv6  <d5f0ff6f233b4b034c222c16438c88d9> /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
0x2fe00000 - 0x2fe26fff  dyld armv6  <544395a4b5546114b878d5131a84fd7f> /usr/lib/dyld
0x30410000 - 0x30536fff  libSystem.B.dylib armv6  <0373fd64e915a17160732b29d343f95f> /usr/lib/libSystem.B.dylib

Thanks for any advice!

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
clint
  • 14,402
  • 12
  • 70
  • 79
  • 1
    Are you using any iOS4 only frameworks (they should be weak-linked)? – christo16 Jul 22 '10 at 21:53
  • No, not that I'm aware of. In fact, the last time the app was built and tested was with SDK 3 and a 3.1.3 device--before iOS 4 was even released. I haven't changed any of the code or libraries since then--I'm just trying to build with SDK 4 for the first time and test on iOS 4 + iOS 3.x. – clint Jul 22 '10 at 22:03

3 Answers3

85

Ben Gottlieb pointed out yesterday that if you use blocks anywhere in your application, you'll see a crash similar to this on a pre-4.0 OS while building with the LLVM compiler. To work around this, you can specify the linker flag -weak-lSystem in your Xcode build settings.

lhunath
  • 120,288
  • 16
  • 68
  • 77
Brad Larson
  • 170,088
  • 45
  • 397
  • 571
  • 16
    Ah, thanks Brad! I was just coming back to share the same solution (after some trial and error)... For anyone else who might come across this and need help setting up the weak link, here's a screenshot: http://img.skitch.com/20100722-f65bkarx79gk8nye52ji834cbn.png Also, note that it doesn't seem to be specific to the LLVM compiler--I'm just using GCC 4.2. – clint Jul 22 '10 at 22:45
  • 1
    @Clint Harris - I think for the LLVM compiler you still need to force the weak-linking using the compiler flag, because it doesn't respect the setting within Xcode's project window there. – Brad Larson Jul 22 '10 at 22:49
  • What does "block" mean in this context? Block to me means a block of code, which I suppose is hardly what you mean here. This solution did fix it for me too btw. Thanks a lot! – quano Jul 25 '10 at 02:47
  • @quano - A block is a new C language construct introduced in Snow Leopard and iOS 4.0. See here for a good introduction to them: http://developer.apple.com/iphone/library/featuredarticles/Short_Practical_Guide_Blocks/index.html – Brad Larson Jul 25 '10 at 03:48
  • Odd, I'm not using any of those, and all my libraries I'm using are working with iPhone OS 3, so I don't understand why it would require me to specify linker flags for things I'm not even using. Oh well, I'm just happy it works. Thanks again. – quano Jul 25 '10 at 04:33
  • 1
    This solution works in the first place, but no I'm getting spontaneous crashes (EXC_BAD_ACCESS) that happen on 3.x devices only and don't leave any stack in the debugger or any console output. I got a crash report after syncing the device which looks kinda suspicious...: http://gist.github.com/659393 (excerpt) – stigi Nov 02 '10 at 09:01
  • @stigi - What method within your application is this crashing in? Does this method happen to update the user interface (I see UIKit in there)? If so, is it doing this on a background thread? UIKit is not threadsafe and updates to the interface on a non-main thread cause just these kind of crashes. – Brad Larson Nov 02 '10 at 13:37
  • No background thread UIKit stuff. We resolved the problem by removing the block code from our static library and removing the weak linking of libSystem.B.dylib. The crash couldn't be related to a specific method call. I tried narrowing the bug down to a specific line of code but this didn't work. Also NSZombie & CFZombie didn't trigger anything. – stigi Nov 02 '10 at 16:18
  • 2
    This solution works fine but I'm getting instant crashes only in the simulator for any Block usage. I resorted to set this flag conditionally only for non-Simulator builds. /cc @stigi – Ortwin Gentz Jun 30 '11 at 14:56
  • 2
    Using -weak-lSystem works on the 3.x device but does NOT crash the simulator. Someone should edit the parent post. – blackjack75 Oct 18 '11 at 21:38
  • Doesn't seem to help in Xcode 4.4. Block release still crashes with "Other Linker Flags" and "Other C Flags" set with -weak-lSystem – jbierling Dec 23 '12 at 06:35
18

Since most of these answers are specific to Xcode 3.x, just wanted to share what I did to fix this with Xcode 4.2.

Under your target in the "Build Phases" tab in the "Link Binary With Libraries" section I added "libSystem.dylib" and made it optional. This fixed the issue iOS 3.x devices while maintaining support for iOS 4.x and 5.0 devices.

Brandon
  • 953
  • 10
  • 12
  • Many thanks. Worked like a charm. No way I would have found out a solution to that cryptic bug without this help. – CuriousMarc May 11 '14 at 01:00
1

If you happen to be using the cocos2d libraries, there is a cleaner way to do this, you should configure the cocos2d target's Deployment target to 3.0

Rafael Nobre
  • 5,062
  • 40
  • 40