Librairie statique, workspace et références
Bonjour à tous,
Nous travaillons actuellement sur une application de démonstration utilisant une librairie statique développée par nos soins.
J'ai notamment suivi la session CocoaHeads #12 de Rennes qui m'a bien servi (merci Olivier):
J'ai suivi les différentes étapes mais je bloque cependant sur un point. L'import du .h de la librairie se passe bien mais le build plante pour des références non-trouvées ("symbol(s) not found"). En effet, la librairie utilise le framework "AudioToolbox" et 4 librairies (.a) qui apportent des méthodes supplémentaires dans le domaine de l'audio notamment (ces 4 librairies n'ont pas été développées en interne).
Est-ce qu'il y a un moyen pour importer uniquement le .a de ma librairie sans ajouter les 4 autres .a et le framework "AudioToolbox" dans l'application de démo? Cela serait plus fastidieux pour les futurs utilisateurs de la librairie. Je pars pour le moment sur un workspace "Application de Démo / Librairie" pour tester et faire évoluer la librairie mais à terme, je souhaiterais distribuer cette librairie (dans l'idéal un unique fichier .a).
Merci beaucoup pour votre aide et à votre disposition pour vous apporter des renseignements supplémentaires!
Thomas
Réponses
Bonjour à tous,
J'ai pu faire quelques recherches sur le sujet aujourd'hui. Je me suis notamment servi de la commande "lipo" pour obtenir une version universelle de ma librairie (qui fonctionne sur le simulateur et sur device).
Je me suis demandé si je ne pouvais pas ajouter via la commande "lipo" les 4 autres librairies mais il semble que cette commande ne permet "que" de réunir 2 versions d'une librairie ne tournant pas sur la même architecture (dans mon cas "Ma Librairie Simulateur" + "Ma Librairie Device" => "Ma Librairie Universelle").
Je suis donc toujours à la recherche d'un moyen d'avoir un unique fichier .a à distribuer contenant ma librairie et les 4 librairies sur lesquelles elle s'appuie (pour que l'utilisateur de la librairie n'ait qu'un unique fichier à inclure au lieu de 5).
Si vous avez des idées/pistes/questions, n'hésitez pas. Encore merci!
Thomas
Tu crées un target dans ton projet, de type "Static Library", qui ne contient aucun code source à compiler (aucun ".m"), mais qui Link avec tes 4 librairies ".a". Quand il va compiler, il va générer donc une librairie statique ".a", qui contiendra la même chose que les 4 .a réunis, mais en une seule lib.
Merci beaucoup Ali pour ta réponse!
Je bloque sur un autre point et ça serait vraiment super d'avoir vos avis. Lorsque je lance l'application de démo utilisant ma librairie statique, j'ai plusieurs lignes de ce type ... :
objc[1315]: Object 0x151230 of class __NSCFDictionary autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
... sur différents types (dictionary, array ...).
Un breakpoint "objc_autoreleaseNoPool" m'indique des soucis sur des appels comme "dictionaryWithObject:forKey", "subarrayWithRange" etc.
J'ai fait quelques recherches et plusieurs réponses remontent souvent le fait d'utiliser "@autoreleasepool" mais je ne suis pas sûr de la manière de l'utiliser. Si ça peut apporter quelques précisions:
1/ Le code qui pose soucis est celui de la librairie statique (avec le template XCode pour librairie statique) et ce dernier ne contient donc pas de fichier "main.m" et donc de "@autoreleasepool".
2/ Je ne détache pas de nouveau thread dans certaines parties du code de la librairie statique mais les lignes en erreur se trouvent dans un AudioInputCallback (et dans des fonctions appelées depuis l'AudioInputCallback). Je ne sais pas si un AudioInputCallback donne lieu à un autre thread et si ça pourrait donc causer un soucis faute de "@autoreleasepool".
Je ne suis pas sûr que l'explication du problème soit très claire. N'hésitez pas si vous avez besoin de renseignements supplémentaires!
Encore merci pour votre aide
Du coup le plus logique serait d'englober le code contenu dans l'AudioInputCallback au sein d'un @autoreleasepool ?
Je ne comprends pas trop pourquoi je n'ai pas les mêmes erreurs dans le thread principal qui n'a, lui non plus, pas d'autoreleasepool (car pas de fichier main.m qui le set).
A moins que ce soit car le thread principal n'est pas kill à la différence de celui l'AudioInputCallback (d'où les messages d'erreur) ?
Merci beaucoup pour ton aide