Bei jedem Import einer Datei aus CocoaPods erhalte ich einen Apple Mach-O Linker-Fehler.
Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_FBSession", referenced from: someFile
ld: symbol(s) not found for architecture arm64
Ich bekomme ungefähr 12 davon für die verschiedenen Pods, die ich benutze.
Ich versuche mit XCode 5 für das iPhone 5S zu bauen.
Ich habe hier verschiedene Lösungen für SO ausprobiert, aber ich habe noch keine davon zum Arbeiten.
Wie behebe ich diesen Apple Mach-O Linker-Fehler?
Ich habe gerade eine andere Warnung gefunden, die interessant sein könnte, ich hoffe, dass ich zur Lösung komme:
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
Wenn Ihre Architekturen und Valid Architectures in Ordnung sind, können Sie überprüfen, ob Sie $(inherited)
hinzugefügt haben, wodurch in Pods generierte Linkerflags zu Other Linker Flags wie folgt hinzugefügt werden:.
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:
Hoffentlich hilft das jemand anderen, auf ein ähnliches Problem zu stoßen, das ich hatte.
Setzen Sie Architectures to armv7 armv7s , Nur aktive Architektur erstellen toNOfür jedes Ziel im Projekt, einschließlich jedes in Pods
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:
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.
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:
Entfernen Sie alle Pods (Pod-Init, Pod-Installation)
Schreiben Sie die Pod-Datei in umgekehrter Reihenfolge um (statt: Pod "Mixpanel", Pod "Intercom", Ich habe verwendet: Pod "Intercom", Pod "Mixpanel" )
Pod installieren
Das Problem wurde behoben, indem Sie die Reihenfolge der Abhängigkeiten in der Pod-Datei umkehren und die Pods neu erstellen.