Undefinierte Symbole für Architektur arm64

Jedes Mal, wenn ich eine Datei von CocoaPods importiere, wird ein Apple Mach-O Linker-Fehler angezeigt.

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 auf SO verschiedene Lösungen ausprobiert, aber noch keine zum Laufen gebracht.

Wie behebe ich diesen Apple Mach-O Linker-Fehler?

Ich habe gerade eine weitere Warnung gefunden, die interessant sein könnte. Ich hoffe, dies führt mich zur Lösung:

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 gültigen Architekturen in Ordnung sind, können Sie überprüfen, ob Sie andere Linker-Flags wie $(inherited)folgt hinzugefügt haben , wodurch in Pods generierte Linker-Flags hinzugefügt werden :

Das Problem ist, dass die Cocoapods noch nicht für die arm64-Architektur erstellt wurden und daher beim Erstellen nicht verknüpft werden können. Wahrscheinlich können Sie diese Pakete erst verwenden, wenn sie aktualisiert wurden und diese Architektur verwenden. Sie können den Linker-Fehler beheben, indem Sie zu 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 nicht die volle Leistung des 64-Bit-Prozessors erhalten. Sie sagten, Sie bauen für die 5er, also kann es einen Grund geben, warum Sie dies brauchen. Wenn Sie aus irgendeinem Grund diese Leistung unbedingt benötigen (vielleicht erstellen Sie gerade ein Spiel) und diese Dateien dringend benötigen, können Sie eine Pull-Anfrage senden und das Projekt dann in arm64 neu kompilieren, indem Sie dieselben Felder in den Dateien, aus denen Sie gezogen haben, auf arm64 setzen die Open Source-Projekte. Aber wenn Sie nicht wirklich brauchen, dass diese Dateien 64-Bit-kompatibel sind, scheint das vorerst ein bisschen übertrieben zu sein.

BEARBEITEN: Einige Leute berichteten auch, dass das Setzen von Build For Active Architectures auf YES ebenfalls 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 das gleiche / ähnliche Problem bei der Implementierung gestoßenAVPictureInPictureController und das Problem war, dass ich das AVKit- Framework in meinem Projekt nicht verknüpft habe.

Die Fehlermeldung lautete:

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. Gehen Sie zu Ihrem Projekt
2. Wählen Sie Ihr Ziel
3. Gehen Sie dann zu Phasen erstellen
4. Öffnen Sie Link Binary With Libraries
5. Zum Schluss fügen Sie einfach + das hinzu AVKit- Framework / ein anderes Framework hinzu .

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

Ich habe auch das gleiche Problem festgestellt, die oben genannten Methoden werden nicht funktionieren. Ich habe versehentlich die Dateien im folgenden Verzeichnis gelöscht.

Ordnerplatzierung:

~ / Library / Developer / Xcode / DerivedData /

Setzen Sie Architekturen auf armv7 armv7s , Build Active Architecture Only auf NO für jedes Ziel im Projekt, einschließlich jedes in Pods

Ich habe meine behoben, indem ich die ausgewählten Implementierungsdateien in der Zielmitgliedschaft auf der rechten Seite überprüft habe. Dies ist insbesondere beim Umgang mit Erweiterungen, dh benutzerdefinierten Tastaturen, nützlich.

Hier sind einige Erklärungen warum build_active_architecture auf NO gesetzt ist. Xcode erkennt nun, welche Geräte Sie angeschlossen haben, und stellt die aktive Architektur entsprechend ein. Wenn Sie also einen iPod Touch der 2. 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 (es sei denn, Sie haben ein großes Projekt, Sie werden den Unterschied möglicherweise nicht bemerken, aber ich denke, die Sekunden summieren sich im Laufe der Zeit).

Wenn Sie eine Verteilungskonfiguration für die Veröffentlichung im App Store erstellen, sollten Sie sicherstellen, dass diese Option nicht aktiviert ist, damit Xcode stattdessen die fette universelle Binärdatei http://useyourloaf.com/blog/2010/04/21/xcode erstellt -build-active-Architecture-only.html

Gelöst nach dem Löschen des Inhalts der DerivedData -> Build -> Produkte -> Debug-iphoneos

Sie müssen nur arm64 aus der gültigen Architektur entfernen und NO auf Nur aktive Architektur setzen . Jetzt einfach reinigen, bauen und ausführen. Sie werden diesen Fehler nicht mehr sehen.

:) KP

Dies hängt möglicherweise mit libz.dyliboder zusammen. Sie libz.tbdmüssen es lediglich zu Ihren Zielen für die Verknüpfungsbinärdateien hinzufügen und erneut versuchen, es zu kompilieren.

Ich habe es gelöst, indem ich gültige Bögen auf armv7 armv7s gesetzt und Build-Architekturen in Release nur auf YES gesetzt und dann eine neue "Pod-Installation" über die Befehlszeile durchgeführt habe

Angesichts eines iPhone 5s und nachdem ich noch keine 64-Bit-Version einer Drittanbieter-Bibliothek erhalten hatte, musste ich mit dem neuesten Xcode in den 32-Bit-Modus zurückkehren (vor 5.1 hat es sich nicht beschwert).

Ich habe dies behoben, indem ich arm64 aus der Liste der gültigen Architekturen gelöscht und dann Build Active Architecture Only auf NO gesetzt habe. Es scheint mir, dass dies sinnvoller ist als umgekehrt, wie oben gezeigt. Ich poste für den Fall, dass andere Leute keine der oben genannten Lösungen für sie finden könnten.

Ich hatte das gleiche Problem nach dem Upgrade auf Xcode 5.1 und habe es behoben, indem ich Architectures auf armv7 armv7s gesetzt habe

War den ganzen Tag in dieser Angelegenheit festgefahren.

Ich hatte mehrere Schemata, es wurde gut für Demo, Internal, Release kompiliert - das Debug-Schema wurde jedoch einfach nicht kompiliert und beschwerte sich über das Fehlen von libPods.a.

Die Lösung bestand darin, zu Projekt -> Ziel -> Build-Einstellungen zu wechseln und "Nur aktive Architektur erstellen" in JA zu ändern. Reinigen und bauen! Endlich Stunden Kopfjucken gelöst!

Einstellen -ObjCauf Other Linker Flagsin Build - Einstellungen des Ziels das Problem gelöst.

Das hat bei mir funktioniert:

ios sdk 9.3

in Ihre Build-Einstellung von app.xcodeproj gültige Architektur: armv7 armv7s Build Aktive Architektur: Nein

Sauber und bauen, für mich gearbeitet.

Das Folgende hat für mich funktioniert, damit GPUImage ohne Fehler auf Xcode 5.1 sowohl für den 64-Bit-Simulator als auch für das Retina iPad Mini ohne kompiliert werden kann dass arm64 aus der Liste der gültigen Architekturen entfernt werden muss (was den Zweck des Besitzes eines 64-Bit-Geräts zum Testen zunichte macht 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 von hier aus 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 "Gruppen für hinzugefügte Ordner erstellen" ebenfalls aktiviert ist. Dadurch werden die generischen Header- / 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 einfach die Gruppe aus Xcode löschen.

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

#import "Source/GPUImage.h" 

Ein paar Dinge, auf die Sie hinweisen sollten:

• Wenn die Fehlermeldung "Kakao" nicht gefunden wird, haben Sie den Mac-Ordner / die Mac-Header zu Ihrem iOS-Projekt hinzugefügt. Löschen Sie einfach die Mac-Gruppe / -Dateien aus Ihrem Projekt, und die Warnung verschwindet
• Wenn Sie den Quellordner (nicht die Gruppe in Xcode) umbenennen, verwenden Sie diesen Namen anstelle von "Source / GPUImage.h" in der Anweisung #import. Wenn Sie den Ordner also vor dem Hinzufügen zu Ihrem Projekt in GPUImageFiles umbenennen, verwenden Sie: #import "GPUImageFiles / GPUImage.h
• Stellen Sie natürlich 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 die richtige Art, GPUImage zu verwenden das hat Brad Larson beabsichtigt, aber es funktioniert für mein aktuelles SpriteKit-Projekt.
• Es ist nicht erforderlich, eine Verknüpfung zu Frameworks / Bibliotheken usw. herzustellen. Importieren Sie einfach den Header und den Quellordner der Implementierung wie oben beschrieben

Hoffe, dass das oben Genannte hilft - es scheint, dass es nirgendwo klare Anweisungen gab, obwohl die Frage mehrmals gestellt wurde, aber keine Angst, GPUImage funktioniert definitiv für die arm64-Architektur!

Dieses Problem trat bei mir nach der Installation eines Pods über Podfile und auf pod install. Nachdem ich eine Reihe verschiedener Korrekturen ausprobiert hatte, importierte ich den Pod schließlich einfach manuell (indem ich die erforderlichen Dateien in mein Projekt zog) und das löste das Problem.

Als Morisunschein Antwort von in die richtige Richtung zeigte, löste eine kleine Änderung in seiner Antwort mein Problem für iOS8.2. Danke an ihn.

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

ARCHS = armv7

VALID_ARCHS = armv6 armv7 armv7s arm64

BUILD ACTIVE ARCHITECTURE ONLY= NO

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

In meinem Fall musste ich suchen

C++ Standard Libraryund stellen Sie sicher, dass das libc++ausgewählt wurde.

Für mich verwende ich opencv 2.4.9 in xcode 7.2 für iOS und die oben genannten Fehler sind aufgetreten. Ich löse die Fehler, indem ich opencv über die Pod-Installation anstelle des Offline-OpenCV-Frameworks verwende.

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

Pod 'OpenCV', '2.4.9'

Keine der Lösungen behebt diesen Fehler in meinem Fall (Xcode 9) mit TesseractOCRiOS. Nach stundenlangem Ausprobieren fand ich eine gute Lösung. Ich lösche gerade 'pod 'TesseractOCRiOS', '~> 4.0.0'in der Podfile, laufen pod install. Fügen Sie dann pod 'TesseractOCRiOS', '~> 4.0.0'wieder hinzu Podfileund führen Sie es pod installerneut aus.

Knall! Es klappt!

"Das OPN [Debug] -Ziel überschreibt die Build-Einstellung OTHER_LDFLAGS." Dies war das Hauptproblem. Nach dem Hinzufügen von $ (geerbt) in einer neuen Zeile in anderen Linker-Flags wurde mein Problem behoben.

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

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

So beheben Sie diesen Fehler:

Geben Sie in der Datei .m die Implementierung für jede Schnittstelle an. 2. neu aufbauen

Ich stand vor dem gleichen Problem. Meine Lösung habe ich hier gefunden: Warum Linker statische Bibliotheken mit Fehlern verknüpfen? iOS

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

Ich habe nach der Installation des AWS-Frameworks das gleiche Problem, um dieses Problem zu beheben. Ich habe die POD-Konfigurationsdatei aus Ihrem Projekt aktualisiert, die 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 richtig funktioniert, setzen Sie Ihr Other Linker-Flag auf $ (geerbt).

Wenn die Architektur- und Linkereinstellungen 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 und verursachten den Linker-Fehler.

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