bonjour,
je me renseigne sur la portabilisation d'une appli dont je possède les sources. C'est une appli en C++.
Je suis tombé la dessus : http://www.commentcamarche.net/faq/15251-portabiliser-une-application-avec-nsis

Et je me demandais ce que signifiait : "Si il y a besoin d'enregistrer une dll/ocx : il ne peut pas être portable non plus."
Parceque j'ai une dll pour faire fonctionner mon appli, mais il suffit que je la pose dans le meme répertoire que mon executable pour que cela fonctionne. Est-ce que cela signifie que je ne pourrai pas portabiliser mon appli

Autre question, pas vraiment en rapport : quand on a besoin d'une dll pour faire fonctionner une appli que l'on a compilé à partir des sources, est-il possible d'inclure cette dll dans l'executable final, de sorte que l'on ne soit pas obligé de trimballer cette dll à coté de l'exécutable à chaque fois.

merci!

"Et je me demandais ce que signifiait : "Si il y a besoin d'enregistrer une dll/ocx : il ne peut pas être portable non plus."
Parceque j'ai une dll pour faire fonctionner mon appli, mais il suffit que je la pose dans le meme répertoire que mon executable"

Utiliser une dll ce n'est pas pareil que l'enregistrer. Si tu as juste besoin d'une dll pour ton programme, effectivement l'inclure dans le dossier de celui-ci sera suffisant généralement.

Pour ta deuxième question tu ne peux pas vraiment inclure une DLL dans un programme comme ça. Tu peux évidemment la copier à l'intérieur de ton programme qui pourra l'écrire sur le disque au démarrage avant de la charger dynamiquement, mais c'est très inélégant et ça demande des droits en écriture.
Pour faire ce que tu veux, tu as besoin d'avoir soit un fichier .lib qui correspond à la DLL (et que tu peux lier statiquement à ton programme) ou alors si tu as les sources de ta DLL comme de ton programme tu peux essayer de tout compiler ensemble. Mais je ne crois pas que tu puisse lier une dll déjà construite avec un exécutable (mais je peux me tromper).

premièrement, on ne dit pas "portabiliser" mais "porter".

Ensuite si tu as un fichier .dll externe dont dépend ton programme et que ce fichier n'est pas construit lors de la compilation, alors tu va effectivement avoir des problèmes. Une dll est une bibliothèque de fonctions pré compilées dans laquelle va se servir le programme quand il en a besoin. Tu peux donc facilement imaginer que ce fichier soit, tout comme ton exécutable, dépendant du système hôte. Par contre il se peut que cette bibliothèque existe aussi sur le système sur lequel tu veux porter ton appli. Dans ce cas il te suffit sans doute de modifier les options de l'étape d'édition des liens dans ton makefile (ou autre processus de compilation).

pour inclure une dll dans une appli il faut compiler en effectuant l'édition des liens de manière statique. Sur gcc/g++ c'est tout simplement l'option "-static" qui s'en occupe.

sous windows tu peux utiliser une dll sans .lib, mais c'est un peux compliquer. Si tu connais le nom de la dll et de la fonction ainsi que son prototype, tu peux appeler loadlibrary ( http://msdn.microsoft.com/en-us/library/ms684175(v=VS.85).aspx ) puis getprocaddress ( http://msdn.microsoft.com/en-us/library/ms683212(VS.85).aspx )pour recuperer un pointeur de fonction sur une fonction exporter de la lib.

"Pour faire ce que tu veux, tu as besoin d'avoir soit un fichier .lib qui correspond à la DLL (et que tu peux lier statiquement à ton programme) "

argh zut il y a donc une différence entre .lib et .dll, ça m'apprendra a donner mon avis sur des questions windows...

Dans ce cas, question : pourquoi ne peut-on pas linker statiquement si on a que la dll ?

une dll c'est l'equivalent du .so et le .lib c'est le .a que tu utilises pour linker.

godrik : sans .lib tu peux utiliser une DLL sans trop de problème si son interface est en C et relativement propre (i.e. les noms de fonctions ne sont pas décorés). Il suffit d'un header avec les fonctions exporté par la bibliothèque et le mot clef declspec(dllimport) (à peu près). C'est du chargement dynamique "statique" (i.e. fait par le loader sans intervention du programmeur).

Les fichiers .lib peuvent être soit des module pour chargé correctement une bibliothèque, dans ce cas là ça permet d'utiliser des bibliothèques avec des interfaces plus complexes, mais ça ne contient pas tout le code de la DLL et donc il n'est quand même pas possible de lier statiquement le programme à la dll. Mais un .lib peut aussi être une version prévu pour être liée statiquement d'une dll.

guyver : il ne s'agit pas ici de porter une application d'une plateforme à une autre, mais, j'imagine, de la "portabiliser", c'est à dire de permettre qu'elle puisse être exécuter de n'importe où (clef usb, répertoire sans privilège particulier, etc.) sans installation.

portabiliser, c'est à dire de permettre qu'elle puisse être exécuter de n'importe où

et bien ; j'étais sacrement a coté de la plaque