SDK 7.1 : mon appli ne compile plus
LeChatNoir
Membre, Modérateur
Salut,
Comme à chaque nouvelle release d'iOS, on (re)découvre les casseroles qu'on se traine...
Cette fois, j'ai un message d'error lors de la phase de "link" qui m'indique que 2 des mes bibliothèques sont ignorées...
Ignoring file ..../libSVGKit-iOS.1.1.0.a, file was built for archive which is not the architecture being linked (x86_64)
Qu'est ce que ça signifie ? Je comprends pas trop...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
- La solution c'est de compiler libSVGKit pour x86_64 si tu peux. Si c'est toi qui la compile (si tu as le code source), il suffit d'activer cette architecture dans les Build Settings si ce n'est pas déjà fait.
- Une autre raison pour laquelle la lib n'aurait pas l'architecture c'est que son projet est peut-être bien configurer pour accepter cette architecture (VALID_ARCHS), mais que tu as configuré le projet pour, pendant les phases de debug, ne compiler que l'architecture sur laquelle tu vas faire les tests, pour éviter de compiler pour toutes les architectures pendant tes phases de debug/test de ton appli. Sauf que si les dépendances de libSVGKit sont mal configurées, libSVGKit ne se sera pas recompilée quand tu lances un test sur x86_64, donc la seule version compilée de la lib qu'il aura trouvé c'est une version compilée précédemment avec une autre architecture que x86_64
Dans tous les cas, tu as un problème de configuration entre le projet libSVGKit et ton projet d'application.
- Déjà , j'espère que tu as utilisé CocoaPods pour intégrer ta lib (si ce n'est pas le cas je ne sais pas comment tu as intégré ton appli, si tu as configuré correctement les choses, et du coup pour t'aider à résoudre cela ça sera moins facile)
- Dans tous les cas, pour résoudre le problème le plus proprement possible, il suffit de sélectionner chacun de tes projets dans Xcode (dans la zone de gauche dite "Project Navigator", sélectionne un des projets bleus), puis d'aller dans le menu "Editor" et choisir "Validate Settings...". Cela va laisser Xcode te suggérer les modifications les plus pertinentes pour régler les inconsistances que tu pourrais avoir dans tes settings. Répète l'opération pour chacun des projets de ton workspace.
nan, j'ai pas utilisé CocoaPod car tu te rappelles, les mecs de SVGKit ne taggent pas leurs versions et j'avais fini par jeter l'éponge...
Mais bon, visiblement, ils ont un peu évoluer sur le sujet et il semblerait qu'on puisse maintenant utiliser CocoaPod.
En tous cas, merci pour les explications. J'avais déjà oublié que j'utilisais une bibliothèque statique !
Hello,
J'utilise aussi SVGKit et j'ai eu le même soucis avec la librairie.
Problème réglé en 1minute en supprimant tout simplement la librairie ainsi que le dossier usr/ de mon projet.
En relançant le projet SVGKIT, en recompilant la librairie et en la rajouant à nouveau avec le dossier usr/ à mon projet.
Un petit tour dans les settings du projet pour vérifier que la librairie va être compilé avec le projet et tout roule.
Ca dépend, dans la soupe on peut ;D
ça se voit qu'il n'as pas installé l'application FoodReporter et il préfère coder que cuisiner
Bon visiblement, on peut utiliser CocoaPod en faisant :
pod "SVGKit", :git => 'https://github.com/SVGKit/SVGKit.git', :branch => '1.x'
A suivre. Je vous tiens au jus.
- Soit en créant ton propre fichier SVGKit.podspec parce que la team de SVGKit n'est pas assez grande pour la créer eux-même, et du coup tu définis les éventuelles dépendances et surtout à quel tag / branche / commit correspond un numéro de version cocoapods (dans 99% des cas quand le composant est bien fait et respecte le semantic versionning, le numéro de version correspond exactement au nom du tag, c'est plus simple, mais quand le composant ne respecte pas du tout les règles pour créer ses tags, au moins tu peux contourner)
- Soit en disant directement dans ton Podfile non pas le nom d'un pod, mais son URL de repo GIT et son tag ou sa branche ou son n° de commit à utiliser, c'est ce que tu as fait
Dans tous les cas, CocoaPods est assez flexible pour te permettre de contourner ceux qui ne respectent pas la stewardship d'un projet OpenSource et font leurs trucs dans leurs coin
Merci Ali. Donc je confirme que ça fonctionne. Il faut cependant faire un update de CocoaPod via un "sudo gem update" car le support de la syntaxe branch=> semble plutot récent (quoique mon CocoaPod devait dater de 6 mois au moins...).
Les développeurs de SVGKit semblent s'ouvrir petit à petit à CocoaPod mais y a encore du boulot (notamment sur les tags).
Donc ça, c'est réglé. Je relance donc mon appli et là : boum. Crash très rapidement.
Log : "findAllSortedBy:ascending:withPredicate:]: unrecognized selector sent to class"
Maintenant, c'est MagicalRecord qui fait des siennes. J'ai pourtant vérifié :
=> mon AppDelegate initialise bien MR
=> la bibliothèque est ok et linkée (via CocoaPod)
=> l'init se déroule bien
Mais dès qu'une de mes classes appelle un "finder" de MR, ça crache avec ce message...
Décidément, la vie de développeur n'est pas un long fleuve tranquille ! Je précise que je ne suis QUE passé en SDK 7.1... Pas de modifs par ailleurs...
Car je suspecte en fait que puisque tu as mis à jour CocoaPods et fait mumuse avec SVGKit, tu as dû à un moment donné faire "pod update" sur ton projet. Ce qui a dû mettre à jour MagicalRecord dans la foulée (si tu ne lui avais pas imposé une version spécifique dans ton Podfile), sur lequel il y a peut-être eu des modifications sur le sujet de l'activation de MR_SHORTHAND...
Chez moi si je veux que MagicalRecord fonctionne sans avoir à préfixer toutes mes méthodes par "MR_", je suis obligé de mettre le "#define MR_SHORTHAND" dans le fichier "Pods-prefix.pch" du projet Pods (et/ou tous les fichiers éventuels Pods-xx-prefix.pch qui #import MagicalRecord si j'ai des pods qui ont une dépendance avec MagicalRecord et l'importent eux-même). Ce qui fait que si tu fais un pod update il faut vérifier que ce "#define MR_SHORTHAND" n'a pas été écrasé par ton update (pour ça MagicalRecord aurait pu mieux configurer son podspec pour proposer des subspecs préconfigurées, mais bon)
Moi je met juste : pod 'MagicalRecord/Shorthand' et j'ai la notation sans MR_.
Je lui avait fait une demande via Merge Request pour qu'il crée des subspecs à la fois pour avec/sans shorthand et pour logs activés/désactivés, pour qu'on puisse choisir la config qu'on veut direct (plutôt que de modifier les fichiers après un pod update) et il ne m'avais jamais répondu... C'est cool si depuis il l'a fait, depuis le temps que j'attends !
Vous êtes mes sauveurs ! Effectivement, j'avais pas vu les #ifdef MR_SHORTHAND !
Ca fonctionne maintenant !
Hourra !
Mes casseroles sont en train de disparaitre
Bon, du coup, j'ai encore un pb sur SVGKit puisque j'avais "tweaké" ma version pour gérer des histoire de resize... Mais je vais retrouver ça rapidos et corrigé direct dans les sources du pod maintenant.
Cool !
Mille mercis
Si jamais les gars de SVGKit ne sont pas assez réactifs à ton goût, il te reste toujours la possibilité de faire un fork du projet SVGKit dans ton GitHub à toi, pour pouvoir y appliquer toi-même tes modifications sur ton propre repo GitHub et sur ta propre version de SVGKit. (De toute façon pour faire une Pull Request c'est justement le principe : tu fais un fork où tu fais tes modifs, et tu faire un "Request" pour que SVGKit "Pull" (Merge) ton code (d'où le nom "Pull Request") dans leur repo, pour récupérer tes correctif chez eux)
- Tu pourras toujours faire pointer ton Podfile vers ton fork (et non plus vers le repo officiel) du coup pour pouvoir profiter de ces modifs sans avoir à les refaire à chaque pod update. Voire profiter de ces modifs sur d'autres projets qui voudraient eux aussi utiliser SVGKit et que ces autres projets profitent aussi de ces modifs/correctifs.
Suite à la version 7.1, J'ai un même problème de link : " linker command failed with exit code 1 (use -v to see invocation)" pour un lien ;"Ld /Users/jbchoisy/Library/Developer/Xcode/DerivedData/easyLag-chhppuyymfjrmpcpsvmallfquqpz/Build/Products/Debug-iphonesimulator/easyLag.app/easyLag normal i386"
Je ne sais pas si je dois faire la même manip que tu as proposé ? je ne trouve pas ce menu "Validate settings..." ?
merci
Ce que tu cites est certes un pb de link, mais je pense pas que ça ait qqch à voir avec le pb initialement exposé ici. C'est quoi l'erreur de link exactement ?
Parce que "linker command failed" c'est trop générique. Même remarque, va dans le Log Navigator et regarde le détail de l'erreur, parce que là j'ai pas ma boule de cristal
Je n'arrive pas à trouver le menu que tu cites ("validae settings").
en fait la totale du Log c'est ça et je ne comprends pas tout :
1) Ton problème n'a rien à faire dans ce thread. L'erreur est clairement indiquée, c'est un "Duplicate symbol" sur le symbole "_flag", entre ton code dans "firstViewController" et celui dans "thirdDetailledFormationViewController". Bref, non seulement c'est dans ton code à toi et rien à voir avec SVGKit, et en plus c'est un problème de duplicate symbol donc rien à voir avec le pb de link évoqué dans ce thread. Du coup merci d'ouvrir un sujet dédié, ça évitera de polluer celui-là
Tu aurais quand même pu un peu lire les lignes que tu as copié/coller, l'erreur y est décrite quand même explicitement... le message d'erreur me semble plutôt précis en plus...
2) Pense à utiliser des balises quand tu rédiges tes messages sur le forum. Là une balise [code] ou
Merci de ton aide Ali. C'est juste bizarre la manière dont tu donnes les réponses.
j'ai lu le titre "New reply to SDK 7.1 : mon appli ne compile plus" et j'ai pensé que cela avait un rapport avec mon problème.
Ce n'était pas clair pour moi. Je n'ai pas de réponse sur "validate settings". Je n'ai pas la prétention de m'appeler la Doc donc je demande de l'aide.
bonne soirée.