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:
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:
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
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:
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.
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:
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é)
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:
Supprimez 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
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!