Symboles indéfinis pour l'architecture arm64

Je reçois une erreur Apple Mach-O Linker chaque fois que j'importe un file de CocoaPods.

Undefined symbols for architecture arm64: "_OBJC_CLASS_$_FBSession", referenced from: someFile ld: symbol(s) not found for architecture arm64 

J'en ai environ 12, pour les différents Pods que j'utilise.

J'essaie de build pour l'iPhone 5S en utilisant XCode 5.

J'ai essayé différentes solutions ici sur SO, mais je n'ai aucun d'entre eux pour fonctionner encore.

Comment réparer cette erreur Apple Mach-O Linker?


Je viens de find un autre avertissement qui pourrait être intéressant, j'espère que cela m'amène à la solution:

 Ignoring file ~/Library/Developer/Xcode/DerivedData/SomeApp/Build/Products/Debug-iphoneos/libPods.a, 

file was built for archive which is not the architecture being linked (arm64):~/Library/Developer/Xcode/DerivedData/someApp/Build/Products/Debug-iphoneos/libPods.a

Si vos architectures et architectures valides sont correctes, vous pouvez vérifier si vous avez ajouté $(inherited) , ce qui appenda les indicateurs de liens générés dans les pods, à d' autres indicateurs de liens comme ci-dessous: entrez la description de l'image ici

Le problème est que les cocoapodes n'ont pas été construits pour l'architecture arm64 mais ils ne peuvent donc pas être liés lorsque vous les construisez. Probablement vous ne pouvez pas utiliser ces packages jusqu'à ce qu'ils soient mis à jour et utilisent cette architecture. Vous pouvez corriger l'erreur de l'éditeur de liens en accédant à project -> target (votre nom de projet) -> build settings et en changeant les architectures en architectures standard (armv7, armv7s) et en architectures valides en armv7, armv7s.

Notez cependant que cela signifie que vous n'obtiendrez pas la pleine puissance du processeur 64 bits. Vous avez dit que vous construisez pour les 5, alors il y a peut-être une raison pour laquelle vous en avez besoin. Si vous avez absolument besoin de ce pouvoir (vous construisez peut-être un jeu) et avez désespérément besoin de ces files, vous pouvez soumettre une requête puis recomstackr le projet en arm64 en définissant ces mêmes champs sur arm64 dans les files que vous avez extraits les projets open source. Mais, à less que vous ayez vraiment besoin de ces files pour être compatible 64 bits, cela semble un peu exagéré pour l'instant.

EDIT: Certaines personnes ont également signalé que la configuration de Build For Active Architectures à YES était également nécessaire pour résoudre ce problème.

En date du 2014-04-28, le réglage devrait ressembler à ceci:

entrez la description de l'image ici

J'ai résolu ce problème en définissant cela:

ARCHS = armv7 armv7s

VALID_ARCHS = armv6 armv7 armv7s arm64

Définissez Architectures sur armv7s, armer l' architecture active uniquement sur NON , pour chaque cible du projet, y compris toutes les cibles.

J'ai également rencontré le même problème, les methods ci-dessus ne fonctionneront pas. J'ai accidentellement supprimé les files dans le directory suivant.

Emplacement du dossier

/ Utilisateur / votrenom / Bibliothèque / Développeur / XCode / DerivedData

entrez la description de l'image ici

Je me suis heurté au même problème en mettant en œuvre AVPictureInPictureController et le problème était que je ne liais pas le framework AVKit dans mon projet.

Le message d'erreur était:

 Undefined symbols for architecture armv7: "_OBJC_CLASS_$_AVPictureInPictureController", referenced from: objc-class-ref in yourTarget.a(yourObject.o) ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation) 

La solution:

  1. Aller à votre projet
  2. Sélectionnez votre cible
  3. Ensuite, allez dans Construire des phases
  4. Ouvrir un lien binary avec des bibliothèques
  5. Enfin, ajoutez + le framework AVKit / tout autre framework .

J'espère que cela aidera quelqu'un d'autre à faire face à un problème similaire.

J'ai corrigé le mien en vérifiant les files d'implémentation sélectionnés dans l'appartenance cible sur le côté droit. Ceci est particulièrement utile pour traiter les extensions, c'est-à-dire les keyboards personnalisés.

Adhésion cible

une explication pourquoi build_active_architecture est défini sur NO. Xcode détecte maintenant les périphériques que vous avez connectés et définira l'architecture active en conséquence. Donc, si vous twigz un iPod Touch de 2ème génération dans votre ordinateur, Xcode doit définir l'architecture active sur armv6. Construire votre cible avec la configuration Debug ci-dessus ne fera que build le binary armv6 pour gagner du time (sauf si vous avez un énorme projet, vous ne remarquerez peut-être pas la différence mais je suppose que les secondes s'additionnent).

Lorsque vous créez une configuration de dissortingbution pour la publication sur l'App Store, vous devez vous assurer que cette option n'est pas définie pour que vous construisiez le gros binary universel http://useyourloaf.com/blog/2010/04/21/xcode-build-active -architecture-only.html

Résolu après la suppression du contenu de DerivedData -> Build -> Produits -> Debug-iphoneos

Je l'ai résolu en définissant des archs valides sur armv7s armv7s et en ne définissant les architectures actives de build que sur YES dans la version, puis en effectuant une nouvelle "installation de pod" à partir de la command line

Étant donné un iPhone 5s et n'ayant pas encore reçu une version 64 bits d'une bibliothèque tierce, j'ai dû returnner en mode 32 bits avec le dernier Xcode (avant le 5.1 il ne se plaignait pas).

J'ai corrigé cela en supprimant arm64 de la list des architectures valides, puis en définissant Build Active Architecture Only sur NO. Il me semble que cela a plus de sens que l'inverse comme indiqué ci-dessus. Je post au cas où d'autres personnes ne pourraient get aucune des solutions ci-dessus pour travailler pour eux.

J'ai eu le même problème après la mise à niveau vers Xcode 5.1 et l' ai corrigé en définissant Architectures à armv7 armv7s

Avait été coincé sur cette question toute la journée.

J'avais plusieurs schémas, il compilait bien pour Demo, Internal, Release – cependant, le système de debugging ne compilait pas et se plaignait du manque de libPods.a.

La solution consistait à accéder au projet -> Cible -> Paramètres de construction et à replace «Construire l'architecture active uniquement» par OUI. Nettoyez et construisez! Enfin des heures de démangeaisons de la tête résolues!

Définition de -ObjC à d' Other Linker Flags -ObjC de -ObjC dans Build Les parameters de la cible ont résolu le problème.

Cela peut être lié à libz.dylib ou libz.tbd , il suffit de l'append à vos cibles pour les binarys de binding, et essayez de comstackr à nouveau.

Ce qui suit a fonctionné pour moi pour get GPUImage comstackr sans erreurs sur Xcode 5.1 pour le simulateur 64 bits et retina iPad Mini, sans avoir besoin de retirer arm64 de la list des architectures valides (qui défait le but de posséder un périphérique 64 bits pour tester Performances 64 bits).

Téléchargez le dossier .zip depuis la page GitHub: https://github.com/BradLarson/GPUImage

Décompressez et naviguez jusqu'au dossier 'framework'. De là, ajoutez et copyz le dossier 'Source' dans votre projet Xcode. Assurez-vous que «Copier les éléments dans le dossier du groupe de destination» est coché et que «Créer des groupes pour les dossiers ajoutés» est également coché. Cela copyra les files d'en-tête / d'implémentation generics, iOS et Mac dans votre projet.

Si vous n'avez pas besoin des files Mac parce que vous comstackz pour iOS, vous pouvez supprimer le dossier Mac avant de copyr les files dans votre projet, ou simplement supprimer le groupe depuis Xcode.

Une fois que vous avez ajouté le dossier Source à votre projet, utilisez ce qui suit pour commencer à utiliser les classs / methods de GPUImage:

 #import "Source/GPUImage.h" 

Quelques points à signaler:

  • Si vous obtenez une erreur indiquant que vous n'avez pas trouvé 'Cocoa', vous avez ajouté le dossier / les en-têtes Mac à votre projet iOS – supprimez simplement le ou les groupes Mac de votre projet et l'avertissement disparaîtra
  • Si vous renommez le dossier Source (pas le groupe dans Xcode), utilisez ce nom au lieu de "Source / GPUImage.h" dans l'instruction # import. Donc, si vous renommez le dossier en GPUImageFiles avant de l'append à votre projet, utilisez: #import "GPUImageFiles / GPUImage.h
  • Évidemment, assurez-vous que arm64 est sélectionné dans la list des architectures valides pour profiter du processeur A7 64 bits!
  • Ce n'est pas un set GPUImage.framework (comme si vous téléchargiez le framework à partir de http://www.raywenderlich.com/60968/ios-7-blur-effects-gpuimage ) donc il se peut que la manière correcte d'utiliser GPUImage ne soit pas correcte que Brad Larson avait l'intention de faire, mais cela fonctionne pour mon projet SpriteKit actuel.
  • Il n'est pas nécessaire de lier des frameworks / bibliothèques etc – il suffit d'importer l'en-tête et le dossier source de l'implémentation comme décrit ci-dessus

J'espère que ce qui précède aide – il semble qu'il n'y avait pas d'instructions claires partout malgré la question posée plusieurs fois, mais ne craignez pas, GPUImage fonctionne vraiment pour l'architecture arm64!

Ce problème s'est produit pour moi après l'installation d'un pod via Podfile et l' pod install . Après avoir essayé un tas de corrections différentes, j'ai finalement importé le Pod manuellement (en faisant glisser les files nécessaires dans mon projet) et cela a résolu le problème.

Comme la réponse de morisunshine a pointé dans la bonne direction, un petit tweak dans sa réponse a résolu mon problème pour iOS8.2. Merci à lui.

J'ai résolu ce problème en définissant cela:

 ARCHS = armv7 VALID_ARCHS = armv6 armv7 armv7s arm64 BUILD ACTIVE ARCHITECTURE ONLY= NO 

Dans mon cas, je devais chercher

C++ Standard Library et assurez-vous que la libc++ était celle sélectionnée.

Cela a fonctionné pour moi:

ios sdk 9.3

dans votre configuration de construction de l' architecture valide d'app.xcodeproj: armv7 armv7s Build Architecture active: Non

Nettoyer et build, a travaillé pour moi.

Pour moi, j'utilise opencv 2.4.9 dans xcode 7.2 pour iOS et les erreurs ci-dessus se sont produites, et je résous les erreurs en utilisant l'installation opencv via pod plutôt que le framework opencv offline.

Vous pouvez essayer en ajoutant le text de pod d'opencv ci-dessous et supprimer le cadre d'opencv hors ligne si vous avez utilisé.

pod 'OpenCV', '2.4.9'

Vous devez simplement supprimer arm64 de l' architecture valide et définir NON pour l' architecture active uniquement . Nettoyez, construisez et exécutez maintenant. Vous ne verrez plus cette erreur.

🙂 KP

Cette solution est la seule qui a fonctionné pour moi: allez dans les parameters CordovaLib et ajoutez arm64 à Validures d'architectures.

J'ai rencontré le même problème après l'installation de l'infrastructure AWS pour résoudre ce problème, j'ai mis à jour le file de configuration POD de votre projet qui a été créé après l'installation de AWS POD. Vérifiez le file de configuration comme ci-dessous

 OTHER_LDFLAGS = $(inherited) -ObjC -l"Pods-AWSAutoScaling" -l" Pods- AWSCloudWatch" -l"Pods-AWSCognito" -l"Pods-AWSCore" -l "Pods-AWSDynamoDB" -l"Pods-AWSEC2" -l"Pods-AWSElasticLoadBalancing" -l"Pods-AWSKinesis" -l"Pods-AWSLambda" -l"Pods-AWSMachineLearning" -l"Pods-AWSS3" -l"Pods-AWSSES" -l"Pods-AWSSNS" -l" Pods-AWSSQS"-l "Pods-AWSSimpleDB" -l"Pods-Bolts" -l"Pods-FMDB" -l"Pods-GZIP" -l"Pods-Mantle" -l"Pods-Reachability" -l"Pods-TMCache" -l"Pods-UICKeyChainStore" -l"Pods-XMLDictionary" -l"sqlite3" -l "z"-framework "Accelerate" -framework "AssetsLibrary" -framework "CoreLocation" -framework "Foundation" -framework "ImageIO" -framework "Security" -framework "SystemConfiguration" -framework "UIKit" -weak_framework "UIKit" OTHER_LIBTOOLFLAGS = $(OTHER_LDFLAGS) 

Si votre file de configuration ne fonctionne pas correctement, réglez l' option Autre Linker sur $ (hérité)

  1. Accédez aux parameters de construction cible.
  2. set BUILD ACTIVE ARCHITECTURE ONLY = NON pour le debugging et la libération
  3. Construire et courir

Si les parameters de l'architecture et de l'éditeur de liens sont corrects, vérifiez vos files h. Mon problème était la même erreur, mais j'avais restructuré les files h et j'ai supprimé une déclaration externe. D'autres files m utilisaient cette variable, provoquant l'erreur de l'éditeur de liens.

Ajout de "Security.framework" a fait l'affaire pour moi.

Je sais que c'est une vieille twig. Cependant, le même problème a commencé à m'arriver après la migration vers la dernière version de CocoaPods (1.0.0) et en essayant de réinstaller tous les pods. J'ai rencontré l'erreur de l'éditeur de liens "Missing symbols for armv64". Curieusement, je l'ai résolu en effectuant les étapes suivantes:

  1. Supprimez tous les pods (pod init, pod install)

  2. Réécrivez le podfile dans l'ordre inverse (au lieu de: pod "Mixpanel", pod "Intercom", j'ai utilisé: pod "Intercom", pod "Mixpanel")

  3. Installation du pod

Inverser l'ordre des dependencies dans le podfile et rebuild les pods a résolu le problème.

Aucune des solutions ne corrige cette erreur dans mon cas (Xcode 9), avec TesseractOCRiOS . Après des heures d'essais et d'erreurs, j'ai trouvé une bonne solution. Je supprime juste 'pod 'TesseractOCRiOS', '~> 4.0.0' dans le Podfile , lance l' pod install . Ensuite, ajoutez le pod 'TesseractOCRiOS', '~> 4.0.0' à Podfile et relancez l' pod install .

Coup! Ça marche!