Niezdefiniowane symbole dla architektury arm64

Za każdym razem, gdy importuję plik z CocoaPods, pojawia się błąd Apple Mach-O Linker.

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_FBSession", referenced from: someFile
ld: symbol(s) not found for architecture arm64

Dostaję około 12 z nich, dla różnych kapsuł, których używam.

Próbuję budować dla iPhone'a 5S za pomocą XCode 5.

Próbowałem różnych rozwiązań tutaj na SO, ale nie mam jeszcze żadnego z nich do pracy.

Jak naprawić ten błąd Apple Mach-O Linker?

Właśnie znalazłem inne ostrzeżenie, które może być interesujące, mam nadzieję, że doprowadzi mnie to do rozwiązania:

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

Jeśli twoje architektury i prawidłowe architektury są w porządku, możesz sprawdzić, czy dodałeś $(inherited), który doda flagi linkera wygenerowane w strąkach, do innych flag linkera, jak poniżej:

Problem polega na tym, że cocoapody nie zostały jeszcze zbudowane dla architektury arm64, więc nie można ich połączyć podczas ich tworzenia. Prawdopodobnie nie można używać tych pakietów, dopóki nie zostaną zaktualizowane i nie będą korzystać z tej architektury. Możesz naprawić błąd linkera, przechodząc do projektu -> cel (nazwa projektu) -> buduj ustawienia i zmieniaj architektury na architektury standardowe (armv7, armv7s), a prawidłowe architektury na armv7, armv7s.

Pamiętaj jednak, że oznacza to, że nie uzyskasz pełnej mocy 64-bitowego procesora. Powiedziałeś, że budujesz dla 5, więc może być jakiś powód, dla którego potrzebujesz tego. Jeśli z jakiegoś powodu absolutnie potrzebujesz tej mocy (być może budujesz grę) i rozpaczliwie potrzebujesz tych plików, możesz przesłać żądanie ściągnięcia, a następnie ponownie skompilować projekt do arm64, ustawiając te same pola na arm64 w plikach, z których ściągałeś projekty open source. Ale jeśli naprawdę nie potrzebujesz tych plików, aby były 64-bitowe, wydaje się to na chwilę przesada.

EDYCJA: Niektóre osoby zgłosiły również, że ustawienie Kompilacji dla aktywnych architektur na TAK było również konieczne do rozwiązania tego problemu.

Od 28.04.2014 ustawienie powinno wyglądać mniej więcej tak:

Rozwiązałem ten problem, ustawiając, że:

ARCHS = armv7 armv7s

VALID_ARCHS = armv6 armv7 armv7s arm64

Natknąłem się na ten sam / podobny problem z implementacją AVPictureInPictureControlleri problem polegał na tym, że nie łączyłem frameworka AVKit w moim projekcie.

Komunikat o błędzie to:

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)

Rozwiązanie:

1. Idź do swojego projektu
2. Wybierz swój cel
3. Następnie przejdź do Fazy ​​budowy
4. Otwórz link binarny z bibliotekami
5. Wreszcie, po prostu dodaj + do AVKit ram / żadnej innej ramy .

Mam nadzieję, że pomoże to komuś innemu napotkać podobny problem.

Spotkałem również ten sam problem, powyższe metody nie będą działać. Przypadkowo usunąłem pliki w następującym katalogu.

Umieszczenie folderu:

~ / Library / Developer / Xcode / DerivedData /

Ustaw Architekty na armv7 armv7s , Zbuduj Aktywną Architekturę tylko na NIE , dla każdego celu w projekcie, w tym każdego w Kapsułach

Naprawiłem mój, sprawdzając wybrane pliki implementacji w docelowym członkostwie po prawej stronie. Jest to przydatne zwłaszcza w przypadku rozszerzeń, tj. Niestandardowych klawiatur.

Oto kilka wyjaśnień dlaczego build_active_architecture jest ustawiony na NIE. Xcode wykrywa teraz podłączone urządzenia i odpowiednio ustawia aktywną architekturę. Więc jeśli podłączysz iPoda Touch 2. generacji do swojego komputera, Xcode powinien ustawić aktywną architekturę na armv6. Budowanie celu przy użyciu powyższej konfiguracji debugowania spowoduje teraz zbudowanie pliku binarnego armv6 w celu zaoszczędzenia czasu (chyba że masz duży projekt, możesz nie zauważyć różnicy, ale wydaje mi się, że sekundy się sumują).

Podczas tworzenia konfiguracji dystrybucji do publikowania w App Store należy upewnić się, że ta opcja nie jest ustawiona, aby Xcode zamiast tego zbudował gruby uniwersalny plik binarny http://useyourloaf.com/blog/2010/04/21/xcode -build-active-architecture-only.html

Rozwiązany po usunięciu zawartości DerivedData -> Kompilacja -> Produkty -> Debugowanie iPhoneos

Musisz po prostu usunąć arm64 z Valid Architecture i ustawić NO na Active Architecture Only . Teraz wystarczy wyczyścić, zbudować i uruchomić. Nie zobaczysz tego błędu ponownie.

:) KP

Może to być związane z libz.dyliblub libz.tbd, po prostu dodaj go do swoich celów dla plików binarnych łączących i spróbuj skompilować ponownie.

Rozwiązałem to, ustawiając prawidłowe archiwa na armv7 armv7s i ustawiając budowanie aktywnych architektur tylko na TAK w wydaniu, a następnie wykonując nową „instalację pod” z linii poleceń

Biorąc pod uwagę iPhone'a 5s i jeszcze nie otrzymując 64-bitowej wersji biblioteki innej firmy, musiałem wrócić do trybu 32-bitowego z najnowszym Xcode (przed 5.1 nie narzekał).

Naprawiłem to, usuwając arm64 z listy Ważnych architektur, a następnie ustawiając opcję Buduj aktywną architekturę tylko na NIE. Wydaje mi się, że ma to większy sens niż na odwrót, jak pokazano powyżej. Piszę na wypadek, gdyby inni ludzie nie mogli uzyskać żadnego z powyższych rozwiązań.

Miałem ten sam problem po aktualizacji do Xcode 5.1 i naprawiłem go poprzez ustawienie Architektur na armv7 armv7s

Utknąłem w tej sprawie przez cały dzień.

Miałem wiele schematów, kompilacja była dobra dla wersji demo, wewnętrznej, wydania - jednak schemat debugowania po prostu się nie skompilował i narzekał na brak libPods.a.

Rozwiązaniem było przejście do Projektu -> Cel -> Ustawienia kompilacji i zmienić „Kompiluj tylko aktywną architekturę” na TAK. Oczyść i buduj! W końcu godziny swędzenia głowy rozwiązane!

Ustawianie -ObjCsię Other Linker Flagsw ustawieniach kompilacji celu rozwiązania problemu.

To działało dla mnie:

ios sdk 9.3

do ustawienia kompilacji poprawnej architektury app.xcodeproj: armv7 armv7s Kompilacja Aktywna architektura: Nie

Czyść i buduj, działało dla mnie.

Poniższe działało dla mnie, aby kompilacja GPUImage bez błędów na Xcode 5.1 zarówno dla 64-bitowego symulatora, jak i dla Retina iPad Mini, bez potrzeby usuwania arm64 z listy Ważnych architektur (co przeczy celowi posiadania 64-bitowego urządzenia do testowania Wydajność 64-bitowa).

Pobierz folder .zip ze strony GitHub: https://github.com/BradLarson/GPUImage

Rozpakuj i przejdź do folderu „framework”. Stąd dodaj i skopiuj folder „Źródło” do swojego projektu Xcode. Upewnij się, że opcja „Kopiuj elementy do folderu grupy docelowej” jest zaznaczona, a opcja „Utwórz grupy dla dowolnych dodanych folderów” jest również zaznaczona. Spowoduje to skopiowanie ogólnych plików nagłówkowych / implementacyjnych iOS i Mac do twojego projektu.

Jeśli nie potrzebujesz plików Mac, ponieważ kompilujesz na iOS, możesz usunąć folder Mac przed skopiowaniem plików do projektu lub po prostu usunąć grupę z Xcode.

Po dodaniu folderu źródłowego do projektu skorzystaj z poniższych poleceń, aby rozpocząć korzystanie z klas / metod GPUImage:

#import "Source/GPUImage.h" 

Kilka rzeczy do podkreślenia:

• Jeśli pojawi się błąd z informacją, że „Kakao” nie zostało znalezione, dodałeś folder / nagłówki Mac do swojego projektu na iOS - po prostu usuń grupę / pliki Mac z twojego projektu, a ostrzeżenie zniknie
• Jeśli zmienisz nazwę folderu źródłowego (nie grupy w Xcode), użyj tej nazwy zamiast „Source / GPUImage.h” w instrukcji #import. Jeśli więc zmienisz nazwę folderu na GPUImageFiles przed dodaniem do projektu, użyj: #import "GPUImageFiles / GPUImage.h
• Oczywiście upewnij się, że arm64 jest zaznaczone na liście Ważnych architektur, aby skorzystać z 64-bitowego procesora A7!
• To nie jest pakiet GPUImage.framework (np. Jeśli pobrałeś ramę z http://www.raywenderlich.com/60968/ios-7-blur-effects-gpuimage ), więc może nie być prawidłowym sposobem użycia GPUImage że Brad Larson zamierzał, ale działa w moim obecnym projekcie SpriteKit.
• Nie ma potrzeby łączenia się z frameworkami / bibliotekami itp. - wystarczy zaimportować nagłówek i folder źródłowy implementacji, jak opisano powyżej

Mam nadzieję, że powyższe pomaga - wydaje się, że nie było nigdzie jasnych instrukcji, pomimo wielokrotnego zadawania pytania, ale nie obawiaj się, GPUImage zdecydowanie działa na architekturę arm64!

Ten problem wystąpił dla mnie po zainstalowaniu zasobnika za pośrednictwem Podfile i pod install. Po wypróbowaniu kilku różnych poprawek w końcu po prostu zaimportowałem Pod ręcznie (przeciągając niezbędne pliki do mojego projektu) i to rozwiązało problem.

Gdy odpowiedź morisunshine wskazywała we właściwym kierunku, drobna poprawka w jego odpowiedzi rozwiązała mój problem z iOS 8.2. Dzięki temu.

Rozwiązałem ten problem, ustawiając, że:

ARCHS = armv7

VALID_ARCHS = armv6 armv7 armv7s arm64

BUILD ACTIVE ARCHITECTURE ONLY= NO

1. Przejdź do docelowych ustawień kompilacji.
2. ustaw TYLKO BUDUJ AKTYWNĄ ARCHITEKTURĘ = NIE dla debugowania i wydania
3. Zbuduj i uruchom

W moim przypadku musiałem szukać

C++ Standard Libraryi upewnij się, że libc++został wybrany.

Dla mnie używam opencv 2.4.9 w xcode 7.2 dla iOS i powyższe błędy wystąpiły, i rozwiązuję błędy, używając opencv poprzez instalację pod, a nie w trybie offline opencv.

Możesz spróbować, dodając poniższy tekst pod opencv i usuwając szkielet opencv offline, jeśli go używałeś.

pod „OpenCV”, „2.4.9”

Żadne z rozwiązań nie naprawia tego błędu w moim przypadku (Xcode 9), przy pomocy TesseractOCRiOS. Po wielu godzinach prób i błędów wymyśliłem dobre rozwiązanie. Po prostu usuwam 'pod 'TesseractOCRiOS', '~> 4.0.0'w Podfile, uruchom pod install. Następnie dodaj z pod 'TesseractOCRiOS', '~> 4.0.0'powrotem Podfilei uruchom pod installponownie.

Huk! To działa!

„Cel OPN [Debugowanie] przesłania ustawienie kompilacji OTHER_LDFLAGS”. To był główny problem. Po dodaniu $ (odziedziczonej) w nowej linii w innych flagach linkera rozwiązałem mój problem.

w niektórych przypadkach, jeśli zdefiniujesz jeszcze jeden interfejs w pliku .h, ale nie zaimplementujesz wszystkich tych interfejsów, wystąpił ten błąd.

Linker nie może znaleźć implementacji w pliku .m, więc musisz zaimplementować ją w pliku .m dla każdego interfejsu.

Aby rozwiązać ten błąd:

1. w pliku .m podaj implementację dla każdego interfejsu. 2. budowanie

Napotkałem ten sam problem. Moje rozwiązanie znalazłem tutaj: Dlaczego linker łączy statyczne biblioteki z błędami? iOS

Dodanie $ (TOOLCHAIN_DIR) / usr / lib / swift / $ (PLATFORM_NAME) do ścieżek wyszukiwania bibliotek rozwiązało problem.

Mam ten sam problem po zainstalowaniu frameworka AWS, aby rozwiązać ten problem, zaktualizowałem plik konfiguracyjny POD z twojego projektu, który został utworzony po zainstalowaniu AWS POD. Sprawdź plik konfiguracyjny jak poniżej

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)   

jeśli plik konfiguracyjny nie działa poprawnie, ustaw flagę Other Linker na $ (dziedziczony)

Jeśli ustawienia architektury i linkera wyglądają dobrze, sprawdź pliki h. Moim problemem był ten sam błąd, ale zrestrukturyzowałem pliki h i usunąłem instrukcję zewnętrzną. Inne pliki m używały tej zmiennej, powodując błąd linkera.

Dodanie „Security.framework” załatwiło sprawę.