Apple Mach-O Linker Błąd podczas kompilacji dla urządzenia

Właśnie uaktualniłem do xcode 4.0 i nie mogę już wdrożyć na iPhonie, pojawia się błąd Apple Mach-O Linker, ale nadal działa dla symulatora.

    Ld /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel normal armv7
    cd /Users/yveswheeler/iParcel
    setenv IPHONEOS_DEPLOYMENT_TARGET 3.2
    setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk -L/Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos -F/Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos -filelist /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel.LinkFileList -dead_strip -all_load -ObjC -lxml2 -miphoneos-version-min=3.2 -framework UIKit -framework CoreGraphics -framework QuartzCore /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Core.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Network.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Style.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UI.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UICommon.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UINavigator.a -framework AddressBook -lz.1.2.3 -framework Foundation -framework CFNetwork -framework MobileCoreServices -framework SystemConfiguration -framework MessageUI -framework AudioToolbox -o /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel

arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Core.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Network.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Style.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UI.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UICommon.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UINavigator.a: No such file or directory
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 failed with exit code 1

Oto trwałe rozwiązanie. Generalnie nadpisywanie projektu może powodować takie problemy. Wypróbuj tę metodę.

-UPDATE - Błąd Clang - Błąd Mach-O Linkera

W niektórych przypadkach okno dziennika błędów wyświetla błąd .xctest, aby go naprawić

-> Wybierz swój projekt

-> Oprócz tego (tuż przed zakładką Ogólne) wybierz plik testowy projektu z menu rozwijanego

-> Istnieje jedna opcja (jak ProjNameTests)

-> W aplikacji hosta wybierz projekt z menu rozwijanego tylko wtedy, gdy pokazuje niestandardowy

GOTOWE!

Stara metoda została usunięta

Miałem ten sam problem i problem polegał na tym, że przypadkowo zaimportowałem plik .m zamiast .h do pliku implementacyjnego - mam nadzieję, że to pomoże

Właśnie natrafiłem na ten sam problem.

Rozwiązanie (dla mnie) = sprawdź swoje frameworki.

W moim przypadku dodałem klasy związane z CoreData bez „CoreData.framework”. Dodanie go rozwiązało skargę MACH_O.

otwórz plik .xcworkspace nie .xcodeproj. Powtarzam otwarty plik .xcworkspace. Wszystkie twoje błędy znikną.

Odp: Problem opisany w tytule:

Na wypadek, gdyby ktokolwiek przegapił oczywiste ...

Ten błąd napotkałem po zainstalowaniu nowej wersji Xcode4 i przeciągnięciu istniejących plików do nowego projektu. Nie zauważyłem, że pole wyboru „dodaj do celów” pozostało niezaznaczone w oknie dialogowym „Wybierz opcje dodawania plików:”. Poprawienie mojego pominięcia w Celach> Fazy kompilacji> Kompiluj źródła rozwiązało problem.

Menu> Produkt> Czysty, dzięki temu działał. Nie jestem pewien co do wszystkich innych. Dodałem zdjęcie do pokazania.

Dziwny błąd. Dla mnie właśnie wyczyściłem i ponownie uruchomiłem Xcode, a problem zniknął.

Poprawka: Ustawienia kompilacji> Włącz kod bitowy> Nie

Żadna z tych odpowiedzi mi nie pomogła. Następnie próbowałem ponownie zainstalować Cocoapods:

pod deintegrate

pod install

Problem rozwiązany!

Problem polegał na tym, że w XCode 4 zależności nie zakładają ustawień architektury głównego projektu, tak jak poprzednio w XCode 3. Musiałem przejść przez wszystkie moje zależności, ustawiając je dla poprawnej architektury.

Miałem to samo i udało mi się go rozwiązać.

W preferencjach xcode karta lokalizacji zmienia wartość w obszarze kompilacji na „ Place build products in locations specified by targets".

Zmagałem się z tym przez chwilę, aw moim przypadku skończyło się to ustawieniem kompilacji pod Ścieżkami wyszukiwania o nazwie FRAMEWORK_SEARCH_PATHS. Pomogło mi to, że wybrałem przycisk „Poziomy”, który wydawał się porównywać mój projekt, cel i ustawienia „Rozwiązane”. Zauważyłem, że moje ustawienie docelowe w jakiś sposób przesłoniło domyślną wartość „$ (dziedziczony)”, a nadpisaną wartością było to, co XCode „rozwiązało” to ustawienie. Kiedy usunąłem zastąpienie, które w tym przypadku określiło wersję 3.2 sdk, błędy linkera zniknęły - podobnie jak ostatnio pojawiły się ostrzeżenia o klasach, w których wywoływałem metody post-4.0.

O tych ostrzeżeniach - nigdy ich nie widziałem, dopóki nie dodałem frameworku MessageUI dla ostatniej zmiany. Podejrzewam, ale nie wiem na pewno, że kiedy dodałem tę platformę, XCode próbował zrobić coś sprytnego, dodając tę ​​zmianę do mojego celu. W żadnym momencie nie zrobiłem tego wyraźnie. Ostrzeżenia dotyczyły na przykład metody URLByAppendingPathComponent NSURL, która pojawiła się dopiero w sdk 4.0. Przed dodaniem frameworku MessageUI nigdy nie otrzymałem tego ostrzeżenia. A ponieważ usunąłem zastąpienie, już ich nie otrzymuję.

Miałem ten problem i import QuartzCorego naprawił.

Zmiana „Kompiluj tylko aktywne architektury” na Tak w CordovaLib.xcodeproj -> Ustawienia kompilacji załatwiło sprawę. wcześniej aplikacja działała na symulatorze, ale nie na urządzeniu.

Może być konieczne zaktualizowanie ustawień kompilacji.

Sprawdź docelową wersję systemu iOS i architekturę procesora, ponieważ możesz nie mieć starych zestawów SDK z XCode 4.

W ustawieniach kompilacji może zostać wyświetlony komunikat „Brakujący zestaw SDK”. Zmień to na cokolwiek dotyczy.

Miałem ten sam problem: przypadkowo usunąłem plik .m, podczas gdy .h był w projekcie. Problem zniknął po przywróceniu pliku .m.

Sprawdź, aby upewnić się, że nie określono określonej ścieżki wyszukiwania w strukturze. jeśli przejdziesz do informacji o obiekcie docelowym i po prostu usuniesz wpisy ścieżki wyszukiwania struktury, powinien użyć ustawień domyślnych dla określonej wersji wdrożenia.

Po prostu próbuję utworzyć category classplik i mam ten dziwny problem ... i wreszcie ...

Niepoprawny sposób utworzenia klasy kategorii, który powoduje problem:

New File-> Cocoa Touch-> Objective-C class, następnie zmodyfikowałem nazwę plików do Klasy Kategorii jak nazwa .. (tj. OriginalClass_CategoryName.h/mdo OriginalClass+CategoryName.h/m, a także zmodyfikowałem zawartość pliku).

Właśnie tutaj:

New File-> Cocoa Touch-> Objective-C category, i automatycznie wygeneruje pliki ( OriginalClass+CategoryName.h/m).

Och, jaki jestem głupi!

Jeśli używasz CoreData i używasz XCode do generowania podklas NSManagedObject dla swoich encji, upewnij się, że generujesz tylko jedną dla każdej encji.

Mój problem polegał na tym, że wygenerował wiele podklas NSManagedObject dla tego samego obiektu (i umieścił je w różnych folderach).

Właśnie usunąłem je wszystkie i ponownie wygenerowałem podklasy NSManagedObject.

Aby dodać do listy dziwnych rzeczy, które rozwiązały ten problem ...

Miałem pewne stałe zmienne CGFloat w takim globalnym pliku nagłówkowym

const NSInteger  globalInteger1 = 2;
const NSInteger  globalInteger2 = 3;

W momencie, gdy je usunąłem, wszystko było w porządku :)

Miałem dokładnie ten sam problem tylko dlatego, że miałem dwie takie same stałe w różnych klasach. Ten problem może również wystąpić, jeśli importujesz plik .m, a nie plik .h

Nie jestem pewien, czy jest to powiązane, ale widząc, że korzystasz z jakichś bibliotek 320, możesz sprawdzić ten post na ich stronie internetowej: http://three20.info/article/2011-03-10-Xcode4-Support

Miałem ten sam problem i go rozwiązałem. W moim przypadku problem spowodował ustawienie „architektury”. W moim pliku projektu, na karcie Ustawienia kompilacji, Architektury zostały ustawione na armv6. Zmieniłem go na Standardowy (armv7), czyściłem i budowałem. Potem zadziałało!

W moim przypadku problemem było określenie różnych architektur w ramach różnych celów. Budowałem swój cel aplikacji za pomocą armv6, armv7 i cocos2d ze standardem (amrv7). Przejdź do ustawień kompilacji i upewnij się, że Twoje architektury zgadzają się na wszystkie cele.

Zbyt dziwnie rozwiązałem ten problem!

Wybierz Cel > Fazy kompilacji > Połącz pliki binarne z bibliotekami :

Usuń wszystkie swoje frameworki i dodaj je ponownie!

Mam nadzieję, że to działa dla Ciebie!

Dla języka Swift ...

Otrzymuję ten błąd „ld: plik jest zbyt mały (długość = 0) ....”

W moim przypadku wystarczy wyczyścić projekt, a następnie go odbudować ..

Kroki:-

1) goto Project -> Clean

2) goto Project -> Build

Mam nadzieję że to pomoże..

To zrobiło dla mnie lewę:

Iść do

1) Produkty> czyste

2) Windows> Projekty

3) Wybierz projekt i kliknij Dane pochodne „ Usuń ”

4) Produkty> Kompilacja

Jedna możliwość: włącz „Usuwanie martwego kodu” w ustawieniach kompilacji Xcode 4.

Inna możliwość: być może przełączyłeś się na używanie LLVM dla niektórych frameworków, które wcześniej używały GCC. Powrót do GCC (lub LLVM GCC) może pozbyć się tych ostrzeżeń.

Przez pomyłkę zdefiniowałem nową stałą o takiej samej nazwie jak istniejąca stała w innym pliku i spowodowało to ten błąd dla mnie przy użyciu xCode 4.3.1. xCode nie narzekał, ale kompilatorowi się to nie podoba.

Naprawiłem ten błąd, edytując „Ścieżki wyszukiwania w bibliotece”

Pojawiło się przede wszystkim dlatego, że przeniosłem kilka folderów, co ostatecznie dało moim ustawieniom kompilacji dwie różne ścieżki wyszukiwania, ponieważ są one automatycznie dodawane do ustawień kompilacji po połączeniu biblioteki / frameworka, ale nie są zawsze usuwane.

Jeśli więc przeniesiesz połączoną bibliotekę / strukturę do innego katalogu i ponownie ją połączysz, będziesz musiał ręcznie edytować ścieżkę wyszukiwania.

Być może uda ci się tego uniknąć poprzez usunięcie biblioteki / frameworka przed przeniesieniem go, ale tego nie przetestowałem.