2010-07-22 10 views
46

Ich verwende Xcode 3.2.3 mit dem iOS 4.0 SDK. Ich habe meine App mit Base SDK = iphoneos4.0, Active SDK = iphoneos4.0, Deployment Target = 3.1.3 und Architecture = standard (arm6 arm7) erstellt. Compiler = GCC 4.2. Wie ich es verstehe, ist dies der richtige Weg zu Build eine App für iOS 4 und 3.iOS 4 App stürzt beim Start unter iOS 3.1.3 ab: Symbol nicht gefunden: __NSConcreteStackBlock

Die App läuft gut auf Geräten mit iOS 4. Aber es stürzt beim Start, wenn Sie versuchen, es auf einem ausführen Gerät mit iOS 3.1.3 (ein 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 

Es scheint ein Problem mit einer ziemlich „low level“ dynamisch gebundenen Bibliothek zu sein, vor meinem main() Funktion selbst aufgerufen wird. Ich habe sogar versucht, das Gerät usw. ohne Erfolg neu zu starten. Hier ist ein Teil des 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 

Vielen Dank für jede Beratung!

+1

Verwenden Sie nur iOS4-Frameworks (sie sollten schwach verknüpft sein)? – christo16

+0

Nein, ich bin mir dessen nicht bewusst. Tatsächlich wurde die App zuletzt mit SDK 3 und einem 3.1.3-Gerät gebaut und getestet - bevor iOS 4 sogar veröffentlicht wurde. Ich habe seither weder den Code noch die Bibliotheken geändert - ich versuche nur, mit SDK 4 zum ersten Mal zu bauen und auf iOS 4 + iOS 3.x zu testen. –

Antwort

85

Ben Gottlieb wies gestern darauf hin, dass wenn Sie Blöcke irgendwo in Ihrer Anwendung verwenden, Sie einen ähnlichen Absturz auf einem Betriebssystem vor 4.0 sehen werden, während Sie mit dem LLVM-Compiler bauen. Um dies zu umgehen, können Sie in Ihren Xcode-Build-Einstellungen das Linker-Flag -weak-lSystem angeben.

+16

Ah, danke Brad! Ich kam gerade zurück, um die gleiche Lösung zu teilen (nach etwas Versuch und Irrtum) ... Für alle anderen, die vielleicht auf dieses Problem stoßen und Hilfe bei der Einrichtung der Schwachstelle benötigen, hier ein Screenshot: http://img.skitch.com /20100722-f65bkarx79gk8nye52ji834cbn.png Beachten Sie auch, dass es nicht spezifisch für den LLVM-Compiler zu sein scheint - ich verwende nur GCC 4.2. –

+1

@Clint Harris - Ich denke, für den LLVM-Compiler müssen Sie immer noch die schwache Verknüpfung mit dem Compiler-Flag erzwingen, weil dort die Einstellung im Xcode-Projektfenster nicht berücksichtigt wird. –

+0

Was bedeutet "blockieren" in diesem Zusammenhang? Blockiere für mich einen Block Code, der wohl kaum das ist, was du hier meinst. Diese Lösung hat es auch für mich behoben. Danke vielmals! – quano

1

Wenn Sie werden mit Hilfe der cocos2d Bibliotheken passieren, gibt es eine sauberere Weg, dies zu tun, können Sie die cocos2d Ziel des Bereitstellungsziel auf 3,0

+0

Haben Sie eine Idee, wie Sie mit den XCode 4-Vorlagen umgehen? Vielen Dank. – fjlksahfob

18

konfigurieren sollten Da die meisten dieser Antworten sind spezifisch für Xcode 3.x, wollte nur teilen, was ich getan habe, um das mit Xcode 4.2 zu beheben.

Unter Ihrem Ziel in der Registerkarte "Build-Phasen" in der "Link Binary mit Bibliotheken" Abschnitt habe ich "libSystem.dylib" hinzugefügt und optional gemacht. Dadurch wurde das Problem mit iOS 3.x-Geräten behoben, während die Unterstützung für iOS 4.x- und 5.0-Geräte beibehalten wurde.

+0

Vielen Dank. Lief wie am Schnürchen. Auf keinen Fall hätte ich ohne diese Hilfe eine Lösung für diesen kryptischen Bug gefunden. – CuriousMarc

Verwandte Themen