Erreur Apple Mach-O Linker lors de la compilation de l'appareil

Je viens de passer à xcode 4.0 et je ne peux plus déployer sur iPhone, je reçois une erreur Apple Mach-O Linker, mais cela fonctionne toujours pour le simulateur.

    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

Voici une solution permanente. Le projet d'écrasement général peut provoquer ce problème. Essayez cette méthode.

-UPDATE - Erreur Clang - Erreur Mach-O Linker

Dans certains cas, la fenêtre du journal des erreurs affichant l'erreur .xctest, pour y remédier

-> Sélectionnez votre projet

-> A côté de cela (juste avant l'onglet Général) sélectionnez votre fichier projectTest dans la liste déroulante

-> Il y a une option (comme ProjNameTests)

-> Dans l'application hôte, sélectionnez votre projet dans la liste déroulante uniquement s'il présente une personnalisation

TERMINÉ!

Ancienne méthode supprimée

J'ai eu le même problème et le problème était que j'ai accidentellement importé un fichier .m au lieu de .h dans un fichier d'implémentation - j'espère que cela aide

Je suis juste tombé sur le même problème.

La solution (pour moi) = vérifiez vos frameworks.

Dans mon cas, j'avais ajouté des classes liées à CoreData sans "CoreData.framework". L'ajout a résolu la plainte de MACH_O.

ouvrir le fichier .xcworkspace et non .xcodeproj. Je répète le fichier .xcworkspace ouvert. Toutes vos erreurs disparaîtront.

Re: Problème tel que décrit dans le titre:

Juste au cas où quelqu'un d'autre manquerait l'évidence ...

Je suis tombé sur cette erreur après avoir installé une nouvelle version de Xcode4 et fait glisser des fichiers existants dans un nouveau projet. Je n'avais pas remarqué que la case «Ajouter aux cibles» n'était pas cochée dans la boîte de dialogue «Choisir les options pour ajouter des fichiers:». La correction de mon omission dans Cibles> Phases de construction> Sources de compilation a résolu le problème.

Menu> Produit> Nettoyer, c'est ce qui l'a fait fonctionner. Je ne suis pas sûr de tout le monde. J'ai ajouté une photo pour montrer.

Erreur bizarre. Pour moi, je viens de nettoyer et de redémarrer Xcode et le problème a disparu.

Correction: Paramètres de construction> Activer le code bit> Non

Aucune de ces réponses ne m'a aidé. Ensuite, j'ai essayé de réinstaller Cocoapods:

pod deintegrate

pod install

Problème résolu!

Le problème était que dans XCode 4, les dépendances n'assumaient pas les paramètres d'architecture du projet principal, comme elles le faisaient auparavant dans XCode 3. J'ai dû parcourir toutes mes dépendances en les définissant pour l'architecture correcte.

J'avais le même et j'ai réussi à le résoudre.

Dans les préférences xcode , l' onglet d' emplacement change la valeur sous l' emplacement de génération en " Place build products in locations specified by targets".

J'ai eu du mal avec cela pendant un petit moment, et dans mon cas, cela a fini par être le paramètre de construction sous les chemins de recherche appelé FRAMEWORK_SEARCH_PATHS. Cela m'a aidé de sélectionner le bouton "Niveaux", qui semblait comparer mes paramètres de projet, de cible et "Résolu". J'ai vu que mon paramètre cible dépassait en quelque sorte la valeur par défaut de "$ (hérité)", et la valeur substituée était ce que XCode "résolvait" le paramètre. Lorsque j'ai supprimé le remplacement, qui dans ce cas spécifiait le SDK 3.2, les erreurs de l'éditeur de liens ont disparu - tout comme certains avertissements récemment apparus sur toutes les classes où j'appelais des méthodes post-4.0.

À propos de ces avertissements - Je ne les ai jamais vus avant d'avoir ajouté le cadre MessageUI pour un changement récent. Je soupçonne, mais je ne suis pas sûr, que lorsque j'ai ajouté ce cadre, XCode a essayé de faire quelque chose d'intelligent en ajoutant ce remplacement à ma cible. Je ne l'ai pas fait explicitement à aucun moment. Les avertissements concernaient, par exemple, la méthode URLByAppendingPathComponent de NSURL, qui n'apparaissait pas avant sdk 4.0. Avant d'ajouter le cadre MessageUI, je n'ai jamais reçu cet avertissement. Et depuis que j'ai supprimé la priorité, je ne les ai plus.

J'ai eu ce problème et l'importation l'a QuartzCorerésolu.

Changer "Build Active Architectures Only" en Yes dans CordovaLib.xcodeproj -> Build Settings a fait l'affaire pour moi. auparavant, l'application s'exécutait sur le simulateur, mais pas sur l'appareil.

Vous devrez peut-être mettre à jour vos paramètres de génération.

Vérifiez la version cible d'iOS et les architectures de processeur, car vous ne disposez peut-être pas des anciens SDK avec XCode 4.

Vous pouvez voir «SDK manquant» dans les paramètres de build. Remplacez cela par ce qui s'applique.

J'ai eu le même problème: j'ai accidentellement supprimé un fichier .m, alors que .h était dans le projet. Le problème a disparu lorsque j'ai restauré le fichier .m.

Vérifiez que vous n'avez pas spécifié de chemin de recherche de framework spécifique. si vous accédez aux informations sur la cible et supprimez simplement les entrées du chemin de recherche du framework, il doit utiliser les valeurs par défaut pour votre version de déploiement spécifiée.

J'essaie juste de créer un category classfichier et j'ai ce problème bizarre ... et enfin ...

Mauvaise façon de créer la classe de catégorie qui cause le problème:

New File-> Cocoa Touch-> Objective-C class, puis j'ai modifié le nom des fichiers en catégorie de classe comme nom .. (c'est- OriginalClass_CategoryName.h/mà- dire en OriginalClass+CategoryName.h/m, et également modifié le contenu du fichier).

Bon chemin ici:

New File-> Cocoa Touch-> Objective-C category, et il générera automatiquement des fichiers ( OriginalClass+CategoryName.h/m).

Oh, comme je suis stupide !!

Si vous utilisez CoreData et que vous utilisez XCode pour générer des sous-classes NSManagedObject pour vos entités, assurez-vous de n'en générer qu'une pour chaque entité.

Mon problème était qu'il générait plusieurs sous-classes NSManagedObject pour la même entité (et les plaçait dans des dossiers différents).

Je viens de les supprimer tous et de régénérer les sous-classes NSManagedObject.

Pour ajouter à la liste des trucs bizarres qui ont résolu ce problème ...

J'avais quelques variables const CGFloat dans un fichier d'en-tête global comme ça

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

Au moment où je les ai retirés, tout allait bien :)

J'ai eu exactement le même problème juste parce que j'avais deux mêmes constantes dans des classes différentes. Vous pouvez également rencontrer ce problème si vous importez un fichier .m et non un fichier .h

Je ne sais pas si c'est lié, mais vu que vous exécutez environ trois20 bibliothèques, vous voudrez peut-être consulter cet article sur leur site Web: http://three20.info/article/2011-03-10-Xcode4-Support

J'ai eu le même problème et je l'ai résolu. Dans mon cas, le paramètre "architectures" a causé le problème. Dans mon fichier de projet, onglet Paramètres de construction, les architectures ont été définies sur armv6. Je l'ai changé en Standard (armv7), nettoyez et construisez. Alors ça a marché!

Dans mon cas, le problème était d'avoir différentes architectures spécifiées sous différentes cibles. Je construisais ma cible d'application avec armv6, armv7 et cocos2d avec Standard (amrv7). Allez dans les paramètres de construction et assurez-vous que vos architectures conviennent à toutes les cibles.

J'ai résolu ce problème trop bizarre!

Allez dans Target > Build Phases > Link Binary avec les bibliothèques :

Supprimez tous vos frameworks et ajoutez-les à nouveau!

J'espère que ça marche pour toi !

Pour la langue Swift ...

J'obtiens cette erreur "ld: fichier trop petit (longueur = 0) ...."

Dans mon cas, je nettoie simplement le projet, puis je le reconstruis ..

Pas:-

1) Projet goto -> Nettoyer

2) Projet goto -> Build

J'espère que cela t'aides..

Cela a fait un tour pour moi:

Aller à

1) Produits> propres

2) Windows> Projets

3) Sélectionnez votre projet et cliquez sur " Supprimer " les données dérivées

4) Produits> Construire

Une possibilité: activez "Suppression du code mort" dans les paramètres de construction de Xcode 4.

Autre possibilité: il se peut que vous ayez opté pour LLVM pour certains frameworks qui utilisaient auparavant GCC. Revenir à GCC (ou LLVM GCC) peut supprimer ces avertissements.

J'ai par erreur défini une nouvelle constante avec le même nom qu'une constante existante dans un fichier différent et cela m'a causé cette erreur en utilisant xCode 4.3.1. xCode ne s'est pas plaint mais le compilateur ne l'aime pas.

J'ai pu corriger cette erreur en modifiant "Chemins de recherche de bibliothèque"

Il a surgi en premier lieu parce que j'avais déplacé quelques dossiers, et cela a fini par donner à mes paramètres de build deux chemins de recherche différents car ils sont automatiquement ajoutés à vos paramètres de build lorsque vous liez une bibliothèque / un framework, mais ils ne le sont pas toujours supprimé.

Donc, si vous déplacez une bibliothèque / infrastructure liée vers un autre répertoire et que vous la reconnectez, vous devrez modifier manuellement le chemin de recherche.

Vous pourriez peut-être esquiver cela en supprimant la bibliothèque / le cadre avant de le déplacer, mais je ne l'ai pas testé.