iOS 4 application se bloque au démarrage sur iOS 3.1.3: Symbole non trouvé: __NSConcreteStackBlock

Je suis sous Xcode 3.2.3 avec le SDK iOS 4.0. J'ai construit mon application avec Base SDK = iphoneos4.0, Active SDK = iphoneos4.0, le Déploiement Target = 3.1.3, et l'Architecture = standard (arm6 arm7). Compilateur = GCC 4.2. Si je comprends bien, ce est la bonne façon de construire une application pour iOS 4 et 3.

L'app fonctionne très bien sur les appareils équipés d'iOS 4. Mais il bloque au démarrage lorsque vous essayez de l'exécuter sur un appareil avec iOS 3.1.3 (un 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

Il semble être un problème assez "bas niveau" liées de manière dynamique de la bibliothèque, AVANT que ma fonction main() obtient même appelé. J'ai même essayé de re-démarrage de l'appareil, etc., avec pas de chance. Voici une partie de la la de crash:

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

Merci pour les conseils!!!

Êtes-vous à l'aide de toute l'iOS4 seulement des cadres (ils devraient être faibles liés)?
Non, pas que je suis au courant. En fait, la dernière fois que l'application a été construit et testé avec SDK 3 et 3.1.3 de l'appareil, avant d'iOS 4 a même été publié. Je n'ai pas modifié le code ou les bibliothèques car alors-je suis juste en train de construire avec le SDK 4 pour la première fois et de tester sur iOS 4 + iOS 3.x.

InformationsquelleAutor Clint Harris | 2010-07-22

85

Ben Gottlieb a souligné, hier, que si vous utilisez des blocs de n'importe où dans votre application, vous verrez un accident similaire à ce sur une pré-4.0 OS lors de la construction avec le compilateur LLVM. Pour contourner ce problème, vous pouvez spécifier l'éditeur de liens drapeau -weak-lSystem dans votre Xcode paramètres de construction.
- Ah, merci Brad! Je venais juste de rentrer de partager la même solution (après quelques essais et erreurs)... Pour quelqu'un d'autre qui pourrait venir à travers ce et besoin d'aide pour configurer le maillon faible, voici une capture d'écran: img.skitch.com/20100722-f65bkarx79gk8nye52ji834cbn.png notez Également qu'il ne semble pas être spécifique à la VERSION du compilateur--je suis juste en utilisant GCC 4.2.
- Harris - je pense que pour le compilateur LLVM vous avez encore besoin de la force de la faiblesse de la liaison à l'aide du compilateur drapeau, parce qu'il ne respecte pas le cadre de Xcode projet de la fenêtre.
- Ce n' "bloc" dans ce contexte? Bloc pour moi, c'est un bloc de code, ce qui je suppose n'est pas vraiment ce que vous voulez dire ici. Cette solution n'a corriger pour moi aussi btw. Merci beaucoup!
- Un bloc est un nouveau langage C construire introduit dans Snow Leopard et iOS 4.0. Voir ici pour une bonne introduction à eux: developer.apple.com/iphone/library/featuredarticles/...
- Bizarre, je ne suis pas en utilisant l'un de ces, et tous mes bibliothèques que j'utilise sont de travail avec l'iPhone OS 3, donc je ne comprends pas pourquoi elle aurait besoin de moi pour spécifier l'éditeur de liens drapeaux pour les choses je ne suis même pas en utilisant. Oh bien, je suis juste content que ça fonctionne. Merci encore.
- Cette solution fonctionne en premier lieu, mais non, je suis spontanée des accidents (EXC_BAD_ACCESS) qui se produisent sur 3.x uniquement avec les appareils et ne laissez pas la pile dans le débogueur ou de toute sortie de la console. J'ai reçu un rapport de crash après la synchronisation de l'appareil, qui ressemble un peu suspect...: gist.github.com/659393 (extrait)
- Quelle méthode au sein de votre application est-ce de s'écraser dans? Cette méthode se produire à la mise à jour de l'interface utilisateur (je vois UIKit là)? Si oui, est-il en train de faire cela sur un thread d'arrière-plan? UIKit n'est pas thread-safe et mises à jour de l'interface sur un non-thread principal à cause de ce genre d'accidents.
- Pas de thread d'arrière-plan UIKit choses. Nous avons résolu le problème en supprimant le bloc de code à partir de notre bibliothèque statique et la suppression de la faiblesse de la liaison de libSystem.B.dylib. L'accident ne pouvait pas être lié à un appel de méthode spécifique. J'ai essayé de rétrécissement, le bug le réduire à une ligne de code mais cela ne fonctionne pas. Aussi NSZombie & CFZombie ne pas déclencher quoi que ce soit.
- Cette solution fonctionne très bien mais je suis instantanée se bloque uniquement dans le simulateur pour toute utilisation des blocs. J'ai eu recours à définir cet indicateur conditionnellement seulement pour les non-Simulateur construit. /cc @stigi
- Aide -faible-lSystem fonctionne sur le 3.x appareil, mais ne se bloque PAS le simulateur. Quelqu'un devrait modifier le parent post.
- Ne semble pas aider dans Xcode 4.4. Bloc se bloque toujours avec "d'Autres Drapeaux de l'éditeur de liens" et "Autres C Drapeaux" set avec -faible-lSystem
InformationsquelleAutor Brad Larson
18

Puisque la plupart de ces réponses sont spécifiques à Xcode 3.x, je voulais juste partager ce que j'ai fait pour résoudre ce avec Xcode 4.2.

Sous votre cible dans les "Phases de construction" dans l'onglet "Lien Binaire Avec les Bibliothèques de la section" j'ai ajouté "libSystem.dylib", et a fait facultatif. Cette correction du problème iOS 3.x appareils, tout en maintenant un soutien pour iOS 4.x et 5.0 appareils.
- Merci beaucoup. A travaillé comme un charme. Je ne l'aurais pas trouvé une solution à ce cryptique bug sans cette aide.
InformationsquelleAutor Brandon
1

Si vous arrive d'être en utilisant la cocos2d bibliothèques, il est le moyen le plus propre pour ce faire, vous devez configurer le cocos2d cible de la cible de Déploiement à 3,0
- Avez-vous une idée de la façon de traiter avec elle sur le XCode 4 modèles? Merci.
InformationsquelleAutor Rafael Nobre

Vous devez vous connecter pour publier un commentaire.