Symboles non définis pour l'architecture arm64
Je reçois une erreur Apple Mach-O Linker à chaque fois que j'importe un fichier 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 divers pods que j'utilise.
J'essaie de construire pour l'iPhone 5S en utilisant XCode 5.
J'ai essayé différentes solutions ici sur SO, mais aucune d'entre elles n'a encore fonctionné.
Comment puis-je réparer cette erreur Apple Mach-O Linker?
Je viens de trouver un autre avertissement qui pourrait être intéressant, j'espère que cela me mènera à 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 corrects, vous pouvez vérifier si vous avez ajouté $(inherited), qui ajoutera des indicateurs d'éditeur de liens générés dans les modules, à Autres indicateurs d'éditeur de liens comme ci-dessous: 
Le problème est que les cocoapodes n’ont pas été construits pour l’architecture arm64 et qu’ils ne peuvent donc pas être liés lorsque vous les construisez. Vous ne pouvez probablement pas utiliser ces packages tant qu'ils ne sont pas mis à jour et qu'ils n'utilisent pas cette architecture. Vous pouvez corriger l'erreur de l'éditeur de liens en allant dans projet -> cible (votre nom de projet) -> construire des paramètres et modifier les architectures en architectures standard (armv7, armv7s), et les architectures valides en armv7, armv7.
Notez cependant que cela signifie que vous n'obtiendrez pas toute la puissance du processeur 64 bits. Vous avez dit que vous construisiez pour les 5, vous avez peut-être besoin de cela. Si, pour une raison quelconque, vous avez absolument besoin de ce pouvoir (peut-être que vous construisez un jeu) et avez-vous désespérément besoin de ces fichiers, vous pouvez soumettre une demande d'extraction, puis recompiler le projet en arm64 en définissant ces mêmes champs sur arm64 dans les fichiers que vous avez extraits. les projets open source. Mais, à moins que vous ayez vraiment besoin que ces fichiers soient compatibles 64 bits, cela semble un peu excessif pour le moment.
EDIT: Certaines personnes ont également signalé qu'il était également nécessaire de définir l'option Construire pour les architectures actives sur OUI pour résoudre ce problème.
À partir du 2014-04-28, le paramètre devrait ressembler à ceci:
J'ai résolu ce problème en définissant ce qui suit:
ARCHS = armv7 armv7s
VALID_ARCHS = armv6 armv7 armv7s arm64
J'ai rencontré le même problème/un problème similaire lors de la mise en œuvre de AVPictureInPictureController. 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:
- Allez dans votre projet
- Sélectionnez votre cible
- Ensuite, allez à Build Phases
- Ouvrez Link Binary With Libraries
- Enfin, ajoutez simplement + le AVKit _ {framework/tout autre framework.
J'espère que cela aidera quelqu'un d'autre à rencontrer un problème similaire que j'ai eu.
J'ai également rencontré le même problème, les méthodes ci-dessus ne fonctionneront pas. J'ai accidentellement supprimé les fichiers du répertoire suivant.
Emplacement du dossier:
~/Library/Developer/Xcode/DerivedData /
Ensemble Architectures to armv7 armv7s , Construire une architecture active uniquement toNO, pour chaque cible du projet, y compris chaque in Pods
J'ai corrigé le mien en vérifiant les fichiers d'implémentation sélectionnés dans l'appartenance cible sur le côté droit. Ceci est particulièrement utile pour traiter les extensions, par exemple les claviers personnalisés.
quelques explications sur la raison pour laquelle build_active_architecture est défini sur NO . Xcode détecte maintenant les périphériques que vous avez connectés et définit l'architecture active en conséquence. Par conséquent, si vous connectez un iPod Touch de deuxième génération à votre ordinateur, Xcode doit définir l'architecture active sur armv6. Construire votre cible avec la configuration de débogage ci-dessus ne générera plus que le binaire armv6 pour gagner du temps (sauf si vous avez un projet énorme, vous ne remarquerez peut-être pas la différence, mais je suppose que les secondes s'additionnent avec le temps).
Lorsque vous créez une configuration de distribution pour la publication sur l'App Store, vous devez vous assurer que cette option n'est pas définie pour pouvoir générer le gros binaire 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
Vous devez simplement supprimer arm64 de Architecture valide et définirNOà Architecture active uniquement . Maintenant, nettoyez, construisez et exécutez. Vous ne verrez plus cette erreur.
:) KP
Avait été coincé sur cette question toute la journée.
J'avais plusieurs schémas, il compilait bien pour Demo, Internal, Release - mais le schéma de débogage ne compilait tout simplement pas et se plaignait du manque de libPods.a.
La solution consistait à aller dans Projet -> Cible -> Configurer les paramètres et à changer "Construire une architecture active uniquement" sur OUI. Nettoyer et construire! Enfin des heures de démangeaisons dans la tête résolues!
Étant donné un iPhone 5s et n'ayant pas encore reçu la version 64 bits d'une bibliothèque tierce, je devais revenir en mode 32 bits avec le dernier Xcode (avant la version 5.1, cela ne se plaignait pas).
J'ai résolu ce problème en supprimant arm64 de la liste des architectures valides, puis en définissant Construire une architecture active uniquement sur NO. Il me semble que cela a plus de sens que l'inverse, comme indiqué ci-dessus. Je poste au cas où d'autres personnes ne pourraient obtenir aucune des solutions ci-dessus pour travailler pour elles.
Cela pourrait être lié à libz.dylib ou libz.tbd, il suffit de l'ajouter à vos cibles pour les fichiers binaires de liaison et essayez de compiler à nouveau.
Je l'ai résolu en définissant des archs valides sur armv7 armv7 et en définissant les architectures actives uniquement sur YES en version, puis en effectuant une nouvelle "installation pod" à partir de la ligne de commande
J'ai eu le même problème après la mise à niveau vers Xcode 5.1 et je l'ai corrigé en réglant Architectures to armv7 armv7s
Cela a fonctionné pour moi:
ios sdk 9.3
dans votre paramètre de construction app.xcodeproj architecture valide: armv7 armv7sBuild Architecture active: non
Nettoyer et construire, a travaillé pour moi.
Définir -ObjC sur Other Linker Flags dans les paramètres de construction de la cible a résolu le problème.
dans certains cas, si vous définissez une interface supplémentaire dans un fichier .h, mais que vous ne l'implémentez pas, cette erreur se produit.
L'éditeur de liens ne peut pas trouver l'implémentation dans le fichier .m, vous devez donc l'implémenter dans votre fichier .m pour chaque interface.
Pour résoudre cette erreur:
1.en fichier .m, fournissez l'implémentation pour chaque interface . 2.rebuild
Comme morisunshine réponse a indiqué 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 ce qui suit:
ARCHS = armv7
VALID_ARCHS = armv6 armv7 armv7s arm64
BUILD ACTIVE ARCHITECTURE ONLY= NO
Ce qui suit a permis à GPUImage de compiler sans erreurs sur Xcode 5.1 pour les simulateurs 64 bits et Retina iPad Mini, sans nécessitant de supprimer arm64 de la liste des architectures valides ( Périphérique 64 bits pour tester les performances 64 bits).
Téléchargez le dossier .Zip à partir de la page GitHub: https://github.com/BradLarson/GPUImage
Décompressez et accédez au dossier 'framework'. À partir de là, ajoutez et copiez le dossier "Source" dans votre projet Xcode. Assurez-vous que l'option "Copier les éléments dans le dossier du groupe de destination" est cochée et que "Créer des groupes pour les dossiers ajoutés" est également coché. Cela copiera les fichiers d’en-tête/d’implémentation génériques, iOS et Mac dans votre projet.
Si vous n'avez pas besoin des fichiers Mac parce que vous compilez pour iOS, vous pouvez supprimer le dossier Mac avant de copier les fichiers dans votre projet ou simplement supprimer le groupe dans Xcode.
Une fois que vous avez ajouté le dossier Source à votre projet, utilisez ce qui suit pour commencer à utiliser les classes/méthodes de GPUImage:
#import "Source/GPUImage.h"
Quelques points à souligner:
- Si vous obtenez une erreur indiquant «Cacao» introuvable, vous avez ajouté le dossier/les en-têtes Mac à votre projet iOS - supprimez simplement le groupe/les fichiers Mac de votre projet et l'avertissement disparaîtra.
- Si vous renommez le dossier Source (pas le groupe dans Xcode), utilisez ce nom à la place de "Source/GPUImage.h" dans l'instruction #import. Donc, si vous renommez le dossier en GPUImageFiles avant d’ajouter à votre projet, utilisez: #import "GPUImageFiles/GPUImage.h
- Evidemment, assurez-vous que arm64 est sélectionné dans la liste des architectures valides pour tirer parti du processeur A7 64 bits!
- Ce n'est pas un bundle GPUImage.framework (comme si vous téléchargiez le framework à partir de http://www.raywenderlich.com/60968/ios-7-blur-effects-gpuimage ) afin que le résultat ne soit pas correct. manière d’utiliser GPUImage que Brad Larson avait prévu, mais cela fonctionne pour mon projet SpriteKit actuel.
- Il n'est pas nécessaire de créer un lien vers des frameworks/bibliothèques, etc. - importez simplement l'en-tête et le dossier source de l'implémentation comme décrit ci-dessus.
Espérons que ce qui précède aide - il semble qu'il n'y ait pas d'instructions claires nulle part malgré la question posée à plusieurs reprises, mais n'ayez crainte, GPUImage fonctionne sans aucun doute pour l'architecture arm64!
Dans mon cas, je devais chercher
C++ Standard Library et assurez-vous que le libc++ était celui sélectionné.
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 viens de supprimer 'pod 'TesseractOCRiOS', '~> 4.0.0' dans la Podfile, exécuter pod install. Ajoutez ensuite pod 'TesseractOCRiOS', '~> 4.0.0' à Podfile et exécutez à nouveau pod install.
Coup! Ça marche!
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'opencv via l'installation de pod au lieu du framework opencv hors ligne.
Vous pouvez essayer en ajoutant le texte du pod opencv ci-dessous et supprimer le framework opencv hors ligne si vous en avez déjà utilisé.
pod 'OpenCV', '2.4.9'
Ce problème est survenu après l'installation d'un pod via Podfile et pod install. Après avoir essayé différentes solutions, j'ai finalement importé le pod manuellement (en faisant glisser les fichiers nécessaires dans mon projet), ce qui a résolu le problème.
Après avoir installé le framework AWS pour résoudre ce problème, j'ai le même problème. J'ai mis à jour le fichier de configuration POD de votre projet, qui est créé après l'installation d'AWS POD. Vérifiez le fichier 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 fichier de configuration ne fonctionne pas correctement, définissez votre indicateur Autre éditeur de liens sur $ (hérité)
Mon problème était que j'avais déjà des SDK Facebook dans mon projet (FBSDKLoginKit et FBSDKCoreKit).
Je n'avais besoin que d'un autre SDK (FBSDKShareKit) et je l'ai importé, ce qui a donné "Architecture de symboles non définis pour arm64".
Comme FBSDKShareKit est dépendant d'une version mise à jour de FBSDKCoreKit, en mettant à jour les autres cadres, tout a fonctionné à nouveau.
"La cible OPN [Debug] remplace le paramètre de construction OTHER_LDFLAGS". C'était le problème principal. Après avoir ajouté $ (hérité) dans la nouvelle ligne de l'éditeur de liens, le problème a été résolu . 
- Accédez aux paramètres de construction cibles.
- définir BUILD ACTIVE ARCHITECTURE ONLY = NO pour Debug et Release
- Construire et exécuter
J'ai fait face au même problème. Ma solution, j'ai trouvé ici: Pourquoi les bibliothèques statiques linker linker avec des erreurs? IOS
Ajout de $ (TOOLCHAIN_DIR)/usr/lib/Swift/$ (PLATFORM_NAME) aux chemins de recherche de la bibliothèque corrige le problème.
Si vous utilisez un fichier .framework/.a écrit par c ++, où vous appelez le code c ++, le fichier doit être remplacé par le fichier .mm.
J'ai perdu une demi-journée dans cette ...
L'ajout de "Security.framework" a été efficace pour moi.
Si l'architecture et les paramètres de l'éditeur de liens semblent bons, vérifiez vos fichiers h. Mon problème était la même erreur, mais j'avais restructuré les fichiers h et j'ai supprimé une déclaration externe. D'autres fichiers utilisaient cette variable, provoquant l'erreur de l'éditeur de liens.
J'ai eu ce problème avec mon cadre/ parapluie 'qui, lorsque je construisais le cadre de second niveau.
J'ai résolu ce problème en modifiant le schéma de construction de mon premier niveau de cadre pour «Périphérique iOS générique». Je pense que cela va changer _CodeSignature, ce qui m'a fait voir la différence lorsque j'ai poussé tout mon 'framework parapluie' vers GitHub.
Je sais que c'est une vieille branche. Cependant, le même problème a commencé à se produire après la migration vers la dernière version de CocoaPods (1.0.0) et la tentative de réinstallation de tous les pods. J'ai rencontré l'erreur de l'éditeur de liens "Symboles manquants pour armv64" . Assez curieusement, je l'ai résolue en procédant comme suit:
Supprimer tous les pods (pod init, Pod install)
Réécrivez le podfile dans l'ordre inverse (au lieu de: Pod "Mixpanel", Pod "Intercom", J'ai utilisé: Pod "Intercom", Pod "Mixpanel" )
Installation du pod
L'inversion de l'ordre des dépendances dans le podfile et la reconstruction des pods ont résolu le problème.