Discussion :

[dabeuliou]

Bonjour à tous,

Je développe une appli C++ pour linux et Windows avec Qt4. Je compile manuellement mes dll et l'exécutable avec gcc (mingw sous windows).

Après pas mal de recherches, je n'ai toujours pas de réponse claire à une question simple : sous windows où dois-je mettre mes dll nécessaires à l'exécution du programme pour que le programme démarre correctement ? J'ai vu que si je les laisse dans le répertoire qui contient l'exe ou si je les mets dans windows\system32 ça fonctionne mais est-il possible de les mettre ailleurs ?
Pour comparer, sous linux il est possible de les mettre un peu n'importe où à condition de rajouter le chemin dans la variable LD_LIBRARY_PATH ou dans ld.so.conf. N'y a-t-il pas une technique similaire sous windows ?

Autre remarque : j'utilise Qt4, mon programme est donc linké dynamiquement avec des dll de Qt. Ces dll sont dans un répertoire quelconque et le système les trouve pourtant. Comment cela marche-t-il dans ce cas ?

Les raisons pour lesquelles je cherche à comprendre ce mécanisme sont :
1 - pour ranger proprement ces fichues dll
2 - pour comprendre, tout bêtement, afin d'être sûr que mon appli se lancera sur n'importe quel poste.

Merci pour votre aide, je commence à désespérer de n'y rien comprendre. Des liens, des bouquins intéressants ou votre expérience perso me seront très utiles.

[Aurelien.Regat-Barrel]

Bonjour à tous,

Bonjour,

Pour comparer, sous linux il est possible de les mettre un peu n'importe où à condition de rajouter le chemin dans la variable LD_LIBRARY_PATH ou dans ld.so.conf. N'y a-t-il pas une technique similaire sous windows ?

Moui. C'est la variable PATH. Si ta dll est dans le PATH, elle sera visible. system32 est dans le PATH. Pour l'algorithme précis de recherche d'une dll:
http://msdn.microsoft.com/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

Autre remarque : j'utilise Qt4, mon programme est donc linké dynamiquement avec des dll de Qt. Ces dll sont dans un répertoire quelconque et le système les trouve pourtant. Comment cela marche-t-il dans ce cas ?

elle doivent être visible, d'une manière ou d'une autre. Analyse ton exe avec dependency walker:
http://www.dependencywalker.com/
clique sur le bouton "C:\", et tu verras le chemin complet vers les dll utilisées.

Les raisons pour lesquelles je cherche à comprendre ce mécanisme sont :
1 - pour ranger proprement ces fichues dll
2 - pour comprendre, tout bêtement, afin d'être sûr que mon appli se lancera sur n'importe quel poste.

Merci pour votre aide, je commence à désespérer de n'y rien comprendre. Des liens, des bouquins intéressants votre expérience perso me seront très utiles.

La méthode préconisée, c'est de mettre ta dll dans le même répertoire que ton exe. Faut pas toucher à system32, etc... faut pas éparpiller les dll n'importe ou. L'exception c'est pour le développement / l'installation de bibliothèques, où là on les met dans le PATH. Mais pour la redistribution d'un exe simple, dans le même répertoire c'est très bien. C'est propre.

Encore plus propre, c'est de compiler en statique => y'a plus de dll. J'ai pas encore testé QT4, mais c'est ce que je fais avec QT3. J'utilise des dll pour la version debug, mais pour la release j'ai un seul gros exe autonome.

[dabeuliou]

Bon, tout d'abord merci pour la réponse rapide, claire et détaillée. J'ai pas encore exploité tous les liens proposés mais je crois que tu m'apportes enfin pas mal de réponses que je cherchais depuis un moment !

J'avais essayé de rajouter le chemin contenant les dll dans le PATH mais ça n'avait pas fonctionné. J'ai dû me gourrer quelque part.

Sinon, je rebondis sur ta proposition de compiler en statique : je pensais effectivement linker les dll de qt en statique histoire de pouvoir faire tourner le programme sur un poste où qt n'est pas installé. Par contre, j'ai découpé mon programme en 4 dll et j'aimerai garder ce découpage pour simplifier le développement ultérieur de plugins.

Encore merci !

[Aurelien.Regat-Barrel]

Ah oui, il faut conserver la dll Qt alors, à moins que tes plugin n'utilisent absolument pas Qt.
Pour le coup du PATH qui marche pas, ça peut être du à la nécessité de se reloguer.

[dabeuliou]

En principe, les plugins ne devraient pas utiliser Qt directement mais une couche intermédiaire définie dans le noyau de mon appli. Sauf erreur de ma part, le plugin ne devrait avoir besoin que de mes dll, pas de celles de Qt.
Mais bon, je ne suis pas très au point sur le sujet du développement de plugins, j'ai encore pas mal de documentation à trouver. As-tu de précieuses infos sur ce sujet ?

Et sinon, je ne m'étais effectivement pas relogué après avoir changé le path. J'essaierai à nouveau.

Merci.

[Matthieu Brucher]

Si tu linkes avec un des .a de Qt, tu auras besoin de la lib.
Les dlls de Qt ne sont pas n'importe où, elles sont dans un dossier contenu dans le PATH.

[dabeuliou]

Si tu linkes avec un des .a de Qt, tu auras besoin de la lib

Euh, c'est embêtant, ça. Je comptais justement linker avec les .a plutôt qu'avec les dll. Ce ne sont pas les librairies statiques, ces .a ?
Comment faire alors ?

[Matthieu Brucher]

Non, les .a sont des indications nécessaires pour lier avec les dlls.
Lorsque tu crées une lib statique, tu as juste un .a - ou un .lib avec les autres compilateurs -. Lorsque tu crées une librairie dynamique, tu as un .dll/.so - sous Linux - et potentiellement un .lib/.a. Ce dernier fichier permet d'indiquer à l'éditeur de lien ce que contient la dll.

[dabeuliou]

Ah ok, je comprends mieux pourquoi j'avais à la fois des .a et des dll alors que j'avais compilé Qt en mode "librairie dynamique". Bon, je m'offrirai une nouvelle compilation de Qt alors !
Quand on aime ...

Merci pour tes précisions, en tout cas.

[Matthieu Brucher]

La version lib dynamique est plus appréciable de mon point de vue car on peut réutiliser les dll à travers les applis.