Aviary SDK - ld: 30 duplicate symbols for architecture x86_64

Réponses

• AliGator Membre, Modérateur

  décembre 2014 #2

  Et c'est quoi les duplicate symbols en question ?

  
  

  Tu peux lister l'erreur pour indiquer lesquels c'est, et surtout d'où ils viennent ?

  
  

   

  
  

  Si ça se trouve un de tes frameworks est précompilé (.dylib ou .a) et inclut déjà  certaines dépendances fortes dans sa lib (ce qui n'est pas très malin)... dépendances que tu as aussi de ton côté dans ton Podfile... et du coup les symboles de ton projet et ceux du framework clashent.

  
  

   

  
  

  Si c'est le cas faut aller fouetter l'auteur pour lui demander de faire un framework indépendant " ou qui a des dépendances faibles (-weak) uniquement au pire.

  
  

  Ou encore mieux, en plus d'un framework indépendant qui n'embarque pas de librairies tierces linkée, qu'il fournisse un podspec qui liste ces frameworks dont il dépend. Comme ça si toi tu en dépends aussi, tu ne les importeras pas en double.

  
  
• muqaddar Administrateur

  décembre 2014 décembre 2014 modifié #3

  Oui, c'était la piste de Céroce aussi.

  
  

   

  
  

  C'est un framework statique avec un .a.

  
  

  Je n'utilise pas les podfiles.

  
  

   

  
  

  Dans tous les cas, pourquoi ça ne foirerait qu'avec le simu (x86_64) ?

  
  

   

  
  

  Un peu plus sur l'erreur:

  
  

  
  
  duplicate symbol _AFPhotoEditorPremiumAddOnNone in:
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/CellarsViewController.o
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/ContactsViewController.o
  
  duplicate symbol _AFPhotoEditorPremiumAddOnHiRes in:
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/CellarsViewController.o
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/ContactsViewController.o
  
  duplicate symbol _AFPhotoEditorPremiumAddOnWhiteLabel in:
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/CellarsViewController.o
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/ContactsViewController.o
  
  duplicate symbol _AFPhotoEditorPremiumAddOnNone in:
  
      /Users/muqaddar/Library/Developer/Xcode/DerivedData/VinoCell_iOS-djumqfmtlrbedccvavpdermfliwk/Build/Intermediates/VinoCell iOS.build/Debug-iphonesimulator/VinoCell.build/Objects-normal/i386/CellarsViewController.o

  
  

  J'en ai 30 comme ça...

  
  

   

  
  

  Je ne comprends pas l'erreur car les classes citées ne font aucun appel au SDK.

  
  

   

  
  

  J'ai passé 6 heures sur ce problème.

  
  

   

  
  

  Pour l'installation:

  
  

  - on drag-drop le framework et le bundle associé dans le projet

  
  

  - on vérifie que c'est bien dans Build Phases

  
  

  - on vérifie que le Framework Search Path est bon, ce qui est mon cas

  
  

  - et on ajoute -ObjC -all_load dans Other Linker flags

  
  

   

  
  

  Tout ça est correct.

  
  

   

  
  

  Capture d'écran 2014-12-16 à  20.57.23.png 182.4K
• muqaddar Administrateur

  décembre 2014 décembre 2014 modifié #4

  En fait, ces symboles n'existent plus: j'ai fait la mise à  jour du SDK parce qu'Apple ne le validera pas à  cause des préfixes des classes AV qui sont maintenant AVY. Donc mise à  jour recommandée par email faite ce matin.

  
  

   

  
  

  Je ne trouve pas les constantes en question qui posent problème _AFPhotoEditorPremiumAddOnNone dans les headers des classes du Framework, puisqu'elles ont été remplacées.

  
  

   

  
  

  Capture d'écran 2014-12-16 à  20.59.10.png 335.6K
• muqaddar Administrateur

  décembre 2014 décembre 2014 modifié #5

  Voilà  ce qu'on trouve sur le ChangeLogs:
  https://developers.aviary.com/docs/ios/changelog
  
   
  IMPORTANT: The class prefix used in the SDK has changed from AF to AVY to address a symbol clash with a private framework introduced by Apple in iOS 8.2. All developers should upgrade to 4.4.0 to prevent any issues stemming from the symbol collision

  
  

   

  
  

  J'ai upgradé en 4.4.0, mais je suis toujours en iOS 8.1... est-ce que ça peut être la source du problème ?

  
  
• AliGator Membre, Modérateur

  décembre 2014 #6

  Et si tu dump les symboles de la lib (avec la commande `nm` " et un petit `grep` pour filtrer les résultats) est-ce que par hasard leur slice x86_64 n'aurait pas gardé les anciens symboles (genre ils ont recompilé leur framework statique vite fait et ont oublié de régénérer cette archi et ont laissé l'ancienne quand ils ont fait leur `lipo`) ?
  
  
  Si ça se trouve c'est leur framework c'est foireux en fait ?
  
  
  Ceci dit, quelle idée de pas utiliser de Podfile toi non plus, je devrais cesser de te parler tu cherches la m*rde aussi 😄
• muqaddar Administrateur

  décembre 2014 décembre 2014 modifié #7

  
  

  
  

  Ceci dit, quelle idée de pas utiliser de Podfile toi non plus, je devrais cesser de te parler tu cherches la m*rde aussi

  
  

  
  

  
  

   

  
  

  Tens, je suis tombé l'autre jour sur un concurrent des Podfiles qui semblait avoir plus d'avantages, mais j'ai omis le nom.

  
  

   

  
  

  
  

  
  

  Et si tu dump les symboles de la lib (avec la commande `nm` " et un petit `grep` pour filtrer les résultats) est-ce que par hasard leur slice x86_64 n'aurait pas gardé les anciens symboles (genre ils ont recompilé leur framework statique vite fait et ont oublié de régénérer cette archi et ont laissé l'ancienne quand ils ont fait leur `lipo`) ?
  
  
  Si ça se trouve c'est leur framework c'est foireux en fait ?

  
  

  
  

  
  

   

  
  

  Y'a de fortes chances.

  
  

  J'ai compris où tu voulais en venir, mais je ne sais pas le tester.

  
  

   

  
  

  Par contre, leur app démo tourne en x86_64...

  
  

   

  
  

  --

  
  

   

  
  

  Par contre, Adobe les a racheté récemment, et on trouve le framework adobisé depuis peu sur le Creative SDK. Donc il faut que je le teste aussi, lui marche peut-être.

  
  
• muqaddar Administrateur

  décembre 2014 décembre 2014 modifié #8

  Du nouveau.

  
  

   

  
  

  J'ai donc téléchargé le framework chez Adobe CreativeSDK.

  
  

  https://creativesdk.adobe.com/docs/ios/#/articles/imageediting/index.html

  
  

   

  
  

  D'ailleurs Adobe s'est contenté de changer le nom des classes en gros...

  
  

   

  
  

  Et paf, j'ai le même soucis avec celui d'Adobe.

  
  

  ça compile pour le device mais jamais sur le simu.

  
  

   

  
  

  La seule différence, c'est que j'ai 100 problèmes de symboles au lieu de 30 sur x86_64.

  
  

   

  
  

  --

  
  

   

  
  

  J'imagine que quelque chose gêne dans mon projet.

  
  
• AliGator Membre, Modérateur

  décembre 2014 décembre 2014 modifié #9

  Tens, je suis tombé l'autre jour sur un concurrent des Podfiles qui semblait avoir plus d'avantages, mais j'ai omis le nom.

  Tu parles de Carthage j'imagine.
  
  C'est un projet qui ne se veut pas forcément directement concurrent de CocoaPods, mais une solution beaucoup plus simpliste : pas de repo centralisé, pas de dépendances transitoires, pas de gestion de version (donc pas de contrôle de conflit de versions entre les diverses dépendances, si A dépend de X et B dépend de X aussi mais dans une version différente, ils ne savent pas gérer).
  
  En bref, c'est une solution simpliste, qui peut aller dans des projets avec des dépendances plates et qui ne se marchent pas sur les pieds (mais qui peut à  mon avis vite être limitant pour des projets d'envergure moyenne à  conséquente).
  
  ---
  
  Mon avis perso c'est qu'ils n'ont pas du tout anticipé la complexité du problème, et imaginent que c'est simple et que ça va marcher à  tous les coups alors qu'ils n'ont imaginé que les cas droits, parfaits, et simples. Quand on regarde leur liste d'issues, on se rend vite compte que beaucoup de monde a des problèmes quand ils l'appliquent à  des projets de la vie de tous les jours. Mais bon, ils n'en sont qu'à  leur débuts.
  
  Le risque c'est que comme c'est GitHub, tout le monde va les suivre sur parole, alors que du peu que je le connais, Justin SS est le genre de gars têtu, fortement drivé par le syndrome du "NIH" (Not Invented Here = je réinvente la roue pour moi à  chaque fois) et qui ne va pas forcément faire un gros effort pour s'assurer que la communauté comprenne bien les impacts d'utiliser Carthage et ses limitations. Ca peut éventuellement être un outil très bien (quand il sera stable et + mature), quand tu as besoin du strict minimum, mais il faut en connaà®tre les nombreuses limitations et conséquences et l'utiliser en connaissance de cause si tu veux pas avoir de surprise en milieu de projet et regretter trop tard.
  
  
  Bon après, ce n'est que mon avis, pour avoir un peu croisé le personnage et vu ses proses, et parce que je commence à  bien connaà®tre les tenants et aboutissants de faire un outil de gestion de dépendance de par mon expérience sur CocoaPods (télécharger un framework ou des sources et les linker à  ton projet est loin de suffire pour faire un outil de gestion de dépendance, ne serait-ce que pour la gestion des versions et conflits). Donc ça n'engage que moi.
  Mais bon, pour la petite histoire, je trouve que le nom qu'il a choisi pour son outil est bien marrant, quand on connaà®t un peu l'histoire et sait que cette ville a été totalement détruite par les romains
• muqaddar Administrateur

  décembre 2014 #10

  
  

  
  

  Tu parles de Carthage j'imagine.
  
  
  C'est un projet qui ne se veut pas forcément directement concurrent de CocoaPods, mais une solution beaucoup plus simpliste : pas de repo centralisé, pas de dépendances transitoires, pas de gestion de version (donc pas de contrôle de conflit de versions entre les diverses dépendances, si A dépend de X et B dépend de X aussi mais dans une version différente, ils ne savent pas gérer).
  
  
  En bref, c'est une solution simpliste, qui peut aller dans des projets avec des dépendances plates et qui ne se marchent pas sur les pieds.

  
  

  
  

  
  

   

  
  

  Oui, je crois que c'était celui-là .
• muqaddar Administrateur

  décembre 2014 #11

  Bon, j'ai lâché l'affaire sur Aviary/Adobe.

  
  

   

  
  

  Céroce m'a conseillé:

  
  

  https://github.com/kishikawakatsumi/PEPhotoCropEditor

  
  

  qui marche excellemment bien et fait tout ce que je veux: du Crop avant tout.

  
  

   

  
  

  Installé en 5 minutes.

  
  

  Testé sur iPhone et iPad, avec rotations.

  
  

   

  
  

  J'ai gagné:

  
  

  - 160 Mo

  
  

  - mon indépendance vis à  vis d'Adobe

  
  

  - du code que je peux modifier à  ma guise

  
  

  - 1 jour de prise de tête

  
  

   

  
  

  J'avais testé 3 autres outils mauvais avant Aviary, donc j'étais resté sur Aviary... Mais Aviary/Adobe c'est un marteau pour tuer une mouche (pour mon cas).

  
  
• samir Membre

  décembre 2014 #12

  
  

  
  

  Bon, j'ai lâché l'affaire sur Aviary/Adobe.

  
  

  
  

  
  

   Et apparemment le code du SDK Adobe n'est pas top

  
  

   

  
  

  https://twitter.com/steipete/status/544845876825292800/photo/1
• AliGator Membre, Modérateur

  décembre 2014 #13

  Beeerk ah ouais quand même... ça inspire pas confiance tout ça :-/
• Draken Membre

  décembre 2014 #14

  
  

  
  

  Tu parles de Carthage j'imagine.
  
  Mais bon, pour la petite histoire, je trouve que le nom qu'il a choisi pour son outil est bien marrant, quand on connaà®t un peu l'histoire et sait que cette ville a été totalement détruite par les romains

  
  

  
  

  
  

  Carthago delenta est