.dylib ou .a ?
tablier
Membre
Je viens de compiler la LibUsb 1.09. J'obtiens une librairie dynamique et une statique. Je vais utiliser une carte Pic déjà montée dans un appareil, voir photo. (je sais, Arduino! mais je n'ai pas le choix). Vaut-il mieux utiliser la librairie dynamique ou la statique?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Sous iOS on n'a pas le droit d'utiliser des dylib autres que celles d'Apple donc on utilise toujours les .a pour les librairies externes.
Mais sous OSX on peut utiliser les deux :
- Utiliser le dylib permet de n'avoir qu'une seule librairie, séparée de ton exécutable, et qui pourra être ensuite utilisée par un ou plusieurs exécutables sans que le code soit dupliqué pour autant. ça a surtout du sens quand tu utilises une dylib que tu installes sur le système pour que les autres applis qui voudraient se linker avec puissent en profiter aussi ; si la dylib est à l'intérieur de ton .app l'intérêt est déjà bien moindre
- Utiliser le .a fait qu'au moment de la compilation de ton .app le code du .a est directement intégré/fusionné au code de exécutable final, et n'est plus dissocié de ce dernier. Du coup tout est inclus dans ton appli. Bien sur ton application est un peu plus grosse (disons que si le code de ton appli seule ferait 2Mo et le code de la lib compilée fait 1Mo alors quand tu vas compiler ton appli et la linker avec le .a tu vas obtenir une appli qui fait 3Mo et sera autonome, alors qu'avec le dylib tu vas avoir ton appli de 2Mo d'un côté, et la dylib de 1Mo de l'autre, donc le total est le même mais reparti en 2 fichiers, mais si une autre appli se link aussi à ta dylib ce 1Mo ne sera pas dupliqué dans le binaire final)
Si tu ne comptes pas développer un framework qui a pour but d'être utilisé ensuite par plusieurs applications, et que tu ne comptés pas compiler d'autres applications plus tard qui utiliseront elles aussi la LibUsb alors autant partir sur le .a ce qui revient donc grosso modo à fusionner le code de la lib et ton code dans un seul binaire.
Si tu comptes plus tard faire d'autres softs qui vont aussi avoir besoin de LibUsb, tu peux alors partir sur l'option de garder LibUsb séparé / indépendant de ton binaire, et donc opter pour la dylib, mais pour que ça ait un intérêt il faut que tu installes la dylib dans les dossiers globaux du système (sur la machine sur laquelle tu vas installer et faire tourner tes applis) bien sûr pour pouvoir l'avoir dans un emplacement commun accessible à toutes tes applis qui seront linkées avec et pas inclure le dylib dans le bundle de ton application a chaque fois, sinon ça perd tout son intérêt. Ce qui sous-entend du coup d'avoir un installer pour ton application qui va installer la dylib dans les dossiers du système si elle n'a pas déjà été installée par un autre installeur avant. Du coup c'est pas aussi direct à installer qu'avec un simple drag&drop car il y a la dylib commune à installer, un peu plus contraignant car il faut faire un installeur avec PackageMaker ou autre, tout ça pour mutualiser la librairie entre plusieurs applications.
Linker avec la dylib mais garder la dylib dans le bundle, qui est une 3ème solution, n'a pas trop d'intérêt je pense (a part si tu n'avais pas le .a et n'avait pas d'autre solution mais ce n'est pas ton cas) quitte à garder la lib pour ton appli sans la partager autant linker avec le .a dans ce cas
Je vais utiliser la librairie statique car le Mac ne sera raccordé qu'à ce seul appareil, donc la librairie ne sera pas partagée.
@FKEV
Je construis un démonstrateur avec un lecteur de bande perforée pour l'association Aconit: http://www.aconit.org
Mon 1er problème est l'ancienneté des Macs que l'association me demande d'utiliser!
Le premier démonstrateur a été fait avec un iMac G3!! Voir ICI