Symboles en double pour l'architecture arm64
Lorsque j'essaie d'exécuter mon projet Xcode, il échoue avec une erreur indiquant que j'ai des symboles en double. J'ai cherché en ligne où trouver ces doublons mais je n'ai pas eu de chance:
Une idée de comment réparer ça?
D'après les erreurs, il semblerait que FacebookSDK.framework inclut déjà les classes Bolts.framework. Essayez de supprimer le Bolts.framework supplémentaire du projet.
Pour moi, cela a aidé de passer le paramètre du compilateur "No Common Blocks" à NO: Cela semble plutôt logique, le paramètre est expliqué ici: A quoi sert GCC_NO_COMMON_BLOCKS?
À l'aide de Xcode 8, l'option "Mettre à jour le projet avec les paramètres recommandés" a activé "Aucun bloc commun" pour mon projet.
Le ramener à OFF a tout arrangé.
Pour moi, c’est que j’ai importé un fichier au format .m pas à celui-ci
Lors de la mise à niveau vers Xcode 8, j'ai reçu un message pour passer aux paramètres recommandés. J'ai accepté et tout a été mis à jour . J'ai commencé à avoir un problème de compilation:
Symbole en double pour XXXX Symbole en double pour XXXX Symbole en double pour XXXX
Un total de 143 erreurs. Nous sommes allés à la cible-> Paramètres de construction -> Aucun bloc commun -> Définissez-le sur NON Cela a résolu le problème. Le problème était que les projets intégrés avaient des blocs de code en commun et n'étaient donc pas en mesure de le compiler. On peut trouver une explication ici .
Cette erreur se produit lorsque Linker tente de lier les fichiers obj. Voici quelques raisons pour lesquelles je pourrais penser à cette erreur:
La fonction/classe dupliquée est définie à deux emplacements/fichiers différents dans le projet et un seul d'entre eux était censé compiler pour toute variante de la commande de construction. Mais d’une manière ou d’une autre, ces deux fichiers ont été compilés dans votre projet. Vous devez donc vérifier vos conditions if-else ou d’autres dépendances qui ajoutent des fichiers src à la liste des fichiers devant être compilés et supprimer le fichier inutile pour votre commande de construction particulière.
La fonction/classe dupliquée est définie accidentellement à deux endroits/fichiers différents du projet. Supprimer la mauvaise définition.
Nettoyez votre répertoire OBJ avant de reconstruire à nouveau. Il pourrait contenir de vieux fichiers obj provenant de vos constructions précédentes et qui pourraient être à l'origine de ce conflit.
P.S, je ne suis pas un expert, mais c’est ainsi que j’ai résolu ce problème lorsque j’y ai fait face. :)
Une autre solution consiste à:
Sélectionnez Projet -> Cible -> Phase de construction -> Compiler la source -> recherche pour le fichier mentionné dans la 3ème dernière ligne d'erreur (Dans votre case BFAppLinkReturnToRefererView.o ).
Ensuite, vous verrez 1 ou 2 fichiers dans le résultat de la recherche.
Supprimez un d’eux et compilez à nouveau . Il devrait recompiler maintenant car il ne reste plus qu'un fichier et plus aucun conflit pour la construction.
Si cela ne fonctionne pas, le fichier contient probablement des erreurs et vous devez les supprimer, puis les recompiler. Cela devrait fonctionner à nouveau.
Au-dessous du travail correctif pour moi .. :)
Step 1: Go to TARGETS -> Build Settings -> No Common Blocks -> No
Step 2: Go to TARGETS -> Build Settings -> enable testability -> No
Remettre à NO résolu le problème!
Dans mon cas, la raison était trop stupide:
J'ai eu un fichier Constant.h où j'avais des macros définies. J'ai pensé faire NSString là-bas. et a fait ceci:
NSString const *kGreenColor = @"#00C34E";
cela posait le problème des symboles en double pour l'architecture arm64 et la commande de l'éditeur de liens a échoué avec le code de sortie 1. La suppression de la ligne const NSString a fonctionné pour moi.
Pour moi, le problème était le style de création de const, qui a fonctionné jusqu’à présent sur iOS8 .. j’avais quelques lignes comme:
int const kView_LayoutCount = 3;
dans mon fichier .h. Six lignes similaires ont abouti à 636 fichiers de l'éditeur de liens une fois que les blocs communs étaient définis sur NO. (14k + si oui). Déplacement des lignes vers .m après suppression de .h de la déclaration de valeur et la compilation était bonne.
J'espère que cela aide les autres!
Eh bien. Parfois, lors de l’utilisation de SDK comme FB ou de bibliothèques comme Vuforia ou GoogleAnalytics, l’ajout d’exemples de projets peut poser le problème du fait qu’ils incluent déjà Frameworks, etc. êtes déjà inclus dans les échantillons
pour résoudre ce problème, allez à Étapes de construction et recherchez des doublons .__Comme (facebookSDK, unityads) et supprimez (extension fichier.o), puis générez à nouveau.
D'après les erreurs, il semblerait que toutes les classes apparaissent plusieurs fois.Trouvez et supprimez les classes sur lesquelles il travaillera.
Je crée AppDelegate.h et le fichier .m en créant plusieurs fois. Donc, cette erreur se produira. Finalement, trouvez et supprimez que les classes ça fonctionne très bien pour moi.
Le problème pour moi était que j'avais manuellement inclus un cadre, mais que ce même cadre était également inclus dans CocoaPods sans que je le sache. Une fois que j'ai enlevé l'un ou l'autre, le problème est parti
Pour moi, j'ai créé une méthode appelée sampleMethod dans ViewController_A et la même méthode dans ViewController_B aussi. Cela m'a causé cette erreur, puis j'ai changé le nom de la méthode dans ViewController_B en secondSampleMethod. Cela a corrigé l'erreur.
Cela semble être une bonne fonctionnalité pour réduire le code et ne pas dupliquer le même code à plusieurs endroits.
J'ai essayé de changer les blocs Non commun de Oui à Non, puis de permettre la testabilité de Oui à Non. Cela n'a pas fonctionné. J'ai vérifié les fichiers en double également dans les phases de construction, mais il n'y a pas de fichiers en double.
vérifiez votre fichier d'inclusion, j'ai eu ce problème parce que j'ai accidentellement importé "nomfichier.m" au lieu de "nomfichier.h", la correction automatique (tabulation) a mis un "m" et non "h".
J'ai eu ce problème parce que je définissais paresseusement une variable dans mon fichier .m en dehors d'une méthode, puis dans un autre fichier .m, je définissais une autre variable portant le même nom en dehors d'une méthode. Cela entraînait un problème de duplication du nom de la variable globale.