Discussion :

[manrugby]

Bonsoir à tous,

Je suis entrain de créer un moteur 2d basé sur SDL et FMOD et je voudrais savoir si c'est possible de réorganiser tous les libs que j'utilise en une seule lib au lieu d'utiliser ma lib et linker toutes les autres(-lSDL -lSDL_image etc...) en utilisant par exemple juste -lmylib, sinon est ce que c'est possible avec les dll?
comme vous le savez pour executer mon programme il lui faudrait toutes les dll
SDL.dll SDL_image.dll etc... est-il possible de créer une seule dll mydll.dll par exemple

j'ai fait quelques recherches sur le web rien de concluant...

Merci d'avance.

[Pouet_forever]

Salut manrugby

Je ne pense pas que ce soit possible.
Déjà parce qu'il te faudrait recompiler tes bibliothèques, donc avoir le code source. Tu ne peux pas avoir le code source de FMOD donc ce n'est pas possible

Sinon si tu as les sources de tes bibliothèques je pense que tu peux tout à fait les rassembler
Bien sûr il faut faire ça intelligement

[Mac LAK]

Tu peux le faire au niveau de librairies statiques en faisant le goret intégral, c'est à dire en fusionnant les divers modules composants ces librairies dans une nouvelle librairie (je crois que c'est ar / ranlib qui permet ça, de mémoire).
Mais bon, c'est crasseux au possible et c'est un nid à emm.... si tu as des dépendances circulaires et/ou imbriquées, c'est hautement dépendant du compilateur utilisé, et c'est contraire à l'esprit même des librairies statiques.

Par contre, si tu fabriques une DLL, alors ses dépendances internes seront résolues à la compilation, et tu n'auras donc qu'une seule et unique librairie d'importation à inclure. Mais à part si tu fais un effort sur les dépendances publiques, ça ne te dispensera pas de fournir les entêtes des librairies incluses pour pouvoir compiler ton exécutable final...

[cmoibal]

Tu peux le faire au niveau de librairies statiques en faisant le goret intégral, c'est à dire en fusionnant les divers modules composants ces librairies dans une nouvelle librairie (je crois que c'est ar / ranlib qui permet ça, de mémoire).
Mais bon, c'est crasseux au possible et c'est un nid à emm.... si tu as des dépendances circulaires et/ou imbriquées, c'est hautement dépendant du compilateur utilisé, et c'est contraire à l'esprit même des librairies statiques.

Par contre, si tu fabriques une DLL, alors ses dépendances internes seront résolues à la compilation, et tu n'auras donc qu'une seule et unique librairie d'importation à inclure. Mais à part si tu fais un effort sur les dépendances publiques, ça ne te dispensera pas de fournir les entêtes des librairies incluses pour pouvoir compiler ton exécutable final..

Bonne explication

Pour conclure, si tes lib sont statiques, on peut dire que c'est possible (à part des exceptions...). Si elles sont dynamiques, personnellement je pense pas ....

[Lavock]

et c'est contraire à l'esprit même des librairies statiques.

Ca peur paraître futile et hors contexte, mais c'est quoi "l'esprit" des librairies statiques ?

[Mac LAK]

Ca peur paraître futile et hors contexte, mais c'est quoi "l'esprit" des librairies statiques ?

De ne pas être "autonomes" d'un point de vue édition de liens STATIQUES : ce ne sont, en gros, que de simples "tar" de fichiers objets, ni plus, ni moins. Ce ne sont pas des entités linkées, pas plus que ne l'est un .o / .obj du moins.
Une DLL ou un exécutable sont, eux, autonomes du point de vue liens statiques.


A opposer au liens dynamiques (chargement JIT de DLL / SO dans le code en fonction du contexte), qui de toutes façons ne se résolvent qu'à l'exécution bien entendu et non pas à la compilation / édition de liens statique... Et qui n'entrent donc pas en ligne de compte à ce niveau : du point de vue du linker, charger une DLL ou ouvrir un fichier, c'est la même chose, il ne fait que linker les primitives adéquates pour charger le fichier et non pas le fichier lui-même.

[Lavock]

OK merci !