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
Odpowiedzi:
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:źródło
Use the $(inherited) flag
ostrzeżenie terminalu. I błąd mnie tu sprowadził. uratował mi dzień.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:
źródło
file
polecenia w Terminalu, aby powiedzieć, jakie architektury obsługuje biblioteka statyczna.Rozwiązałem ten problem, ustawiając, że:
ARCHS = armv7 armv7s
VALID_ARCHS = armv6 armv7 armv7s arm64
źródło
Natknąłem się na ten sam / podobny problem z implementacją
AVPictureInPictureController
i problem polegał na tym, że nie łączyłem frameworka AVKit w moim projekcie.Komunikat o błędzie to:
Rozwiązanie:
Mam nadzieję, że pomoże to komuś innemu napotkać podobny problem.
źródło
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 /
źródło
Ustaw Architekty na armv7 armv7s , Zbuduj Aktywną Architekturę tylko na NIE , dla każdego celu w projekcie, w tym każdego w Kapsułach
źródło
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.
źródło
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
źródło
Rozwiązany po usunięciu zawartości DerivedData -> Kompilacja -> Produkty -> Debugowanie iPhoneos
źródło
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
źródło
Może to być związane z
libz.dylib
lublibz.tbd
, po prostu dodaj go do swoich celów dla plików binarnych łączących i spróbuj skompilować ponownie.źródło
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ń
źródło
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ń.
źródło
Miałem ten sam problem po aktualizacji do Xcode 5.1 i naprawiłem go poprzez ustawienie Architektur na armv7 armv7s
źródło
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!
źródło
Ustawianie
-ObjC
sięOther Linker Flags
w ustawieniach kompilacji celu rozwiązania problemu.źródło
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.
źródło
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:
Kilka rzeczy do podkreślenia:
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!
źródło
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.źródło
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:
źródło
źródło
W moim przypadku musiałem szukać
C++ Standard Library
i upewnij się, żelibc++
został wybrany.źródło
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”
źródło
Ż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'
wPodfile
, uruchompod install
. Następnie dodaj zpod 'TesseractOCRiOS', '~> 4.0.0'
powrotemPodfile
i uruchompod install
ponownie.Huk! To działa!
źródło
„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.
źródło
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
źródło
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.
źródło
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
jeśli plik konfiguracyjny nie działa poprawnie, ustaw flagę Other Linker na $ (dziedziczony)
źródło
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.
źródło
Dodanie „Security.framework” załatwiło sprawę.
źródło