Undefinierte Symbole für Architektur arm64

Das Problem ist, dass die Cocoapods nicht für die arm64-Architektur gebaut wurden und daher beim Bau nicht verbunden werden können. Wahrscheinlich können Sie diese Pakete nicht verwenden, bis sie aktualisiert wurden und diese Architektur verwenden. Sie können den Linker-Fehler beheben, indem Sie unter Projekt -> Ziel (Ihr Projektname) -> Einstellungen erstellen und Architekturen in Standardarchitekturen (Armv7, Armv7s) und gültige Architekturen in Armv7, Armv7s ändern. 

Beachten Sie jedoch, dass Sie damit nicht die volle Leistung des 64-Bit-Prozessors erhalten. Sie sagten, Sie bauen für die 5er, also gibt es einen Grund, warum Sie das brauchen. Wenn Sie diese Leistung aus irgendeinem Grund unbedingt benötigen (vielleicht bauen Sie ein Spiel) und Sie diese Dateien dringend benötigen, können Sie eine Pull-Anforderung absenden und das Projekt anschließend erneut in arm64 kompilieren, indem Sie diese Felder in den von Ihnen abgerufenen Dateien auf arm64 setzen die Open-Source-Projekte. Wenn Sie jedoch nicht unbedingt eine 64-Bit-Kompatibilität dieser Dateien benötigen, scheint das für den Moment etwas übertrieben zu sein.

BEARBEITEN: Einige Leute berichteten auch, dass die Einstellung von Build For Active Architectures auf YES erforderlich war, um dieses Problem zu lösen.

Ab dem 28.04.2014 sollte die Einstellung ungefähr so ​​aussehen:

Ich habe dieses Problem gelöst, indem ich Folgendes eingestellt habe:

ARCHS = armv7 armv7s

VALID_ARCHS = armv6 armv7 armv7s arm64

Ich bin auf dasselbe/ähnliche Problem gestoßen, bei dem AVPictureInPictureController implementiert wurde, und das Problem war, dass ich das AVKit - Framework in meinem Projekt nicht verlinkt.

Die Fehlermeldung war:

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)

Die Lösung:

1. Gehe zu deinem Projekt
2. Wählen Sie Ihr Ziel  
3. Dann gehe zu Build Phases
4. Open Binär mit Bibliotheken verknüpfen
5. Zum Schluss fügen Sie einfach + das AVKit Framework / ein beliebiges anderes Framework hinzu.

Hoffentlich hilft das jemand anderen, auf ein ähnliches Problem zu stoßen, das ich hatte.

Ich bin auch auf das gleiche Problem gestoßen, die oben genannten Methoden funktionieren nicht. Ich habe versehentlich die Dateien im folgenden Verzeichnis darauf gelöscht.

Ordnerablage: 

~/Library/Entwickler/Xcode/DerivedData /

Setzen Sie Architectures to armv7 armv7s , Nur aktive Architektur erstellen toNOfür jedes Ziel im Projekt, einschließlich jedes in Pods

Ich habe mein Problem behoben, indem ich die ausgewählten Implementierungsdateien in der Zielmitgliedschaft auf der rechten Seite überprüfte. Dies ist insbesondere beim Umgang mit Erweiterungen, z. B. benutzerdefinierten Tastaturen, nützlich.

einige Erklärungen, warum build_active_architecture auf NO ..__ gesetzt ist. Xcode erkennt jetzt, welche Geräte Sie angeschlossen haben, und setzt die aktive Architektur entsprechend. Wenn Sie also einen iPod Touch der zweiten Generation an Ihren Computer anschließen, sollte Xcode die aktive Architektur auf armv6 setzen. Wenn Sie Ihr Ziel mit der obigen Debug-Konfiguration erstellen, wird jetzt nur die armv6-Binärdatei erstellt, um Zeit zu sparen (sofern Sie kein großes Projekt haben, bemerken Sie möglicherweise den Unterschied nicht, aber ich denke, die Sekunden summieren sich im Laufe der Zeit.).

Wenn Sie eine Distributionskonfiguration für die Veröffentlichung im App Store erstellen, sollten Sie sicherstellen, dass diese Option nicht so eingestellt ist, dass Sie die fette Universal-Binärdatei erstellen http://useyourloaf.com/blog/2010/04/21/ xcode-build-active-architecture-only.html

Wird gelöst, nachdem der Inhalt von DerivedData -> Build -> Products -> Debug-iphoneos gelöscht wurde

Sie müssen nur arm64 from Valid Architecture entfernen undNOauf Active Architecture Only setzen. Jetzt nur reinigen, bauen und ausführen. Sie werden diesen Fehler nicht mehr sehen. 

:) KP

War den ganzen Tag in dieser Frage steckengeblieben.

Ich hatte mehrere Schemes, es war gut für das Kompilieren für Demo, Internal, Release - aber das Debug-Schema würde einfach nicht kompilieren und beschwerte sich über das Fehlen von libPods.a. 

Die Lösung bestand darin, zu Project -> Target -> Build Settings zu gehen und "Nur aktive Architektur erstellen" in YES zu ändern. Reinigen und bauen! Endlich Stunden Kopfjucken gelöst!

Da ich ein iPhone 5s hatte und noch keine 64-Bit-Version einer Drittanbieter-Bibliothek erhalten habe, musste ich mit dem neuesten Xcode in den 32-Bit-Modus zurückkehren (vor 5.1 wurde nichts beanstandet). 

Dies wurde behoben, indem arm64 aus der Liste "Gültige Architekturen" gelöscht und dann "Nur aktive Architektur erstellen" auf "Nein" gesetzt wurde. Es scheint mir, dass dies sinnvoller ist als umgekehrt, wie oben gezeigt. Ich poste, falls andere Leute keine der oben genannten Lösungen bekommen könnten, um für sie zu arbeiten.

Dies könnte sich auf libz.dylib oder libz.tbd beziehen. Sie müssen es lediglich zu Ihren Zielen für die verknüpften Binärdateien hinzufügen und versuchen, es erneut zu kompilieren.

Ich habe das Problem gelöst, indem Sie gültige Bögen auf armv7 armv7s gesetzt und aktive Architekturen nur in JA auf Release gesetzt haben und dann eine neue "Pod-Installation" von der Befehlszeile aus durchführen

Ich hatte das gleiche Problem nach dem Upgrade auf Xcode 5.1 und behebte das Problem durch Setzen von Architectures to armv7 armv7s

Das hat für mich funktioniert:

ios sdk 9.3 

in Ihre Buildeinstellung von app.xcodeproj gültige Architektur: armv7 armv7sBuild Aktive Architektur: Nein

Reinigen und bauen, arbeitete für mich.

Das Setzen von -ObjC auf Other Linker Flags in den Build-Einstellungen des Ziels hat das Problem gelöst. 

in einigen Fällen trat dieser Fehler auf, wenn Sie eine weitere Schnittstelle in einer .h-Datei definieren, diese Schnittstelle jedoch nicht implementiert haben.

Der Linker kann die Implementierung nicht in der .m-Datei finden. Daher müssen Sie sie für jede Schnittstelle in Ihre .m-Datei implementieren.

So beheben Sie diesen Fehler:

1.In der .m-Datei geben Sie die Implementierung für jede Schnittstelle an . 2.rebuild

Als morisunshine Antwort in die richtige Richtung zeigte, löste ein kleiner Tweak in seiner Antwort mein Problem für iOS8.2.

Ich habe dieses Problem gelöst, indem ich Folgendes eingestellt habe:

ARCHS = armv7

VALID_ARCHS = armv6 armv7 armv7s arm64

BUILD ACTIVE ARCHITECTURE ONLY= NO

Das Folgende funktionierte für mich, damit GPUImage unter Xcode 5.1 fehlerfrei kompiliert wird, sowohl für den 64-Bit-Simulator als auch für das iPad Mini, , ohne dass arm64 aus der Liste der gültigen Architekturen entfernen muss (was den Zweck des 64 Bitgerät zum Testen der 64-Bit-Leistung).

Laden Sie den ZIP-Ordner von der GitHub-Seite herunter: https://github.com/BradLarson/GPUImage

Entpacken Sie und navigieren Sie zum Ordner "Framework". Fügen Sie hier den Ordner "Source" hinzu und kopieren Sie ihn in Ihr Xcode-Projekt. Stellen Sie sicher, dass "Elemente in den Ordner der Zielgruppe kopieren" aktiviert ist, und dass auch "Gruppen für hinzugefügte Ordner erstellen" aktiviert ist. Dadurch werden die generischen Kopfzeilen-/Implementierungsdateien für iOS und Mac in Ihr Projekt kopiert. 

Wenn Sie die Mac-Dateien nicht benötigen, weil Sie für iOS kompilieren, können Sie den Mac-Ordner entweder löschen, bevor Sie die Dateien in Ihr Projekt kopieren, oder die Gruppe einfach aus Xcode löschen.

Nachdem Sie den Quellordner zu Ihrem Projekt hinzugefügt haben, verwenden Sie einfach die folgenden Anweisungen, um die Klassen/Methoden von GPUImage zu verwenden: 

#import "Source/GPUImage.h" 

Ein paar Dinge zu beachten:

• Wenn Sie eine Fehlermeldung erhalten, die besagt, dass "Cocoa" nicht gefunden wurde, haben Sie die Mac-Ordner Header zu Ihrem iOS-Projekt hinzugefügt. Löschen Sie einfach die Mac-Gruppe/-Dateien aus Ihrem Projekt. Die Warnung verschwindet
• Wenn Sie den Quellordner umbenennen (nicht die Gruppe in Xcode), verwenden Sie diesen Namen anstelle von "Source/GPUImage.h" in der Anweisung #import. Wenn Sie den Ordner vor dem Hinzufügen zu Ihrem Projekt in GPUImageFiles umbenennen, verwenden Sie: #import "GPUImageFiles/GPUImage.h
• Stellen Sie sicher, dass arm64 in der Liste der gültigen Architekturen ausgewählt ist, um den A7 64-Bit-Prozessor zu nutzen! 
• Dies ist kein GPUImage.framework-Bundle (z. B. wenn Sie das Framework von/- http://www.raywenderlich.com/60968/ios-7-blur-effects-gpuimage heruntergeladen haben), daher ist es möglicherweise nicht das richtige So können Sie GPUImage verwenden, das Brad Larson vorgesehen hat, aber es funktioniert für mein aktuelles SpriteKit-Projekt. 
• Es besteht keine Notwendigkeit, eine Verknüpfung zu Frameworks/Bibliotheken usw. herzustellen - importieren Sie einfach den Header und den Implementierungsquellordner wie oben beschrieben

Hoffe, das obige hilft - es scheint, dass es trotz der mehrfach gestellten Frage an keiner Stelle klare Anweisungen gab, aber keine Angst, GPUImage funktioniert definitiv für die arm64-Architektur!

In meinem Fall musste ich suchen 

C++ Standard Library und vergewissern Sie sich, dass der libc++ ausgewählt wurde.

Keine der Lösungen behebt diesen Fehler in meinem Fall (Xcode 9) mit TesseractOCRiOS. Nach stundenlangem Ausprobieren hatte ich eine gute Lösung gefunden. Ich lösche einfach 'pod 'TesseractOCRiOS', '~> 4.0.0' in der Podfile und führe pod install aus. Fügen Sie dann pod 'TesseractOCRiOS', '~> 4.0.0' wieder zu Podfile hinzu und führen Sie pod install erneut aus. 

Knall! Es klappt! 

Für mich verwende ich opencv 2.4.9 in xcode 7.2 für iOS. Die oben genannten Fehler sind aufgetreten. Ich löse die Fehler, indem ich die Installation von opencv through pod anstelle des offline-opencv-Frameworks verwende.

Sie können es versuchen, indem Sie den opencv-Pod-Text unten hinzufügen und das offline-opencv-Framework löschen, falls Sie es verwendet haben.

pod 'OpenCV', '2.4.9'

Dieses Problem trat für mich nach der Installation eines Pods über Podfile und pod install auf. Nachdem ich verschiedene Fixes ausprobiert hatte, importierte ich den Pod schließlich manuell (indem er die erforderlichen Dateien in mein Projekt zog), und das Problem wurde behoben. 

Nach der Installation des AWS-Frameworks habe ich dasselbe Problem, um dieses Problem zu beheben. Ich habe die POD-Konfigurationsdatei aus Ihrem Projekt aktualisiert, das nach der Installation von AWS POD erstellt wird. Überprüfen Sie die Konfigurationsdatei wie folgt

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)   

wenn Ihre Konfigurationsdatei nicht ordnungsgemäß funktioniert, setzen Sie Ihr Other Linker-Flag auf $ (geerbt). 

Mein Problem war, dass ich bereits einige Facebook SDKs in meinem Projekt hatte (FBSDKLoginKit und FBSDKCoreKit).

Ich brauchte nur noch ein weiteres SDK (FBSDKShareKit) und importierte es, wodurch "undefinierte Symbolarchitektur für arm64" entstand.

Da das FBSDKShareKit von einer aktualisierten Version von FBSDKCoreKit abhängig ist, funktionierte es durch das Aktualisieren der anderen Frameworks erneut.

Msgstr "Das OPN [Debug] Ziel überschreibt die Buildeinstellung OTHER_LDFLAGS." Das war das Hauptproblem. Nach dem Hinzufügen von $ (geerbt) in einer neuen Zeile in anderen Linker-Flags wurde mein Problem gelöst .  

1. Gehe zu den Ziel-Build-Einstellungen.
2. setzen Sie BUILD ACTIVE ARCHITECTURE ONLY = NO für Debug und Release
3. Bauen und ausführen

Ich stand vor dem gleichen Problem. Meine Lösung fand ich hier: Warum Linker Link statische Bibliotheken mit Fehlern? IOS

Hinzufügen von $ (TOOLCHAIN_DIR)/usr/lib/Swift/$ (PLATFORM_NAME) zu den Bibliothekssuchpfaden hat das Problem behoben.

Wenn Sie eine von c ++ geschriebene .framework/.a-Datei verwenden, in der Sie den c ++ - Code aufrufen, muss die betreffende Datei in eine .mm-Datei geändert werden.

Ich habe einen halben Tag damit verloren ...

Das Hinzufügen von "Security.framework" hat den Trick für mich gemacht.

Wenn die Einstellungen für Architektur und Linker gut aussehen, überprüfen Sie Ihre h-Dateien. Mein Problem war der gleiche Fehler, aber ich hatte die h-Dateien umstrukturiert und eine externe Anweisung entfernt. Andere m-Dateien verwendeten diese Variable, was den Linker-Fehler verursachte. 

Ich hatte dieses Problem mit meinem " Umbrella-Framework ", als ich das Second-Level-Framework baute. 

Ich habe dieses Problem gelöst, indem ich das Erstellungsschema meines ersten Levels für "Generic iOS Device" geändert habe. Ich denke, das wird _CodeSignature ändern, was ich den Unterschied gesehen habe, als ich mein gesamtes "Umbrella-Framework" zu GitHub übertrug.

Ich weiß, das ist ein alter Zweig. Das gleiche Problem trat jedoch bei mir auf, nachdem ich auf die neueste CocoaPods-Version (1.0.0) umgestiegen war und versuchte, alle Pods neu zu installieren. Ich bin auf den Linker-Fehler "Missing symbols for armv64" gestoßen Seltsamerweise habe ich ihn gelöst, indem ich die folgenden Schritte ausgeführt habe:

1. Entfernen Sie alle Pods (Pod-Init, Pod-Installation)

2. Schreiben Sie die Pod-Datei in umgekehrter Reihenfolge um (statt: Pod "Mixpanel", Pod "Intercom", Ich habe verwendet: Pod "Intercom", Pod "Mixpanel" )

3. Pod installieren

Das Problem wurde behoben, indem Sie die Reihenfolge der Abhängigkeiten in der Pod-Datei umkehren und die Pods neu erstellen.