Discussion :

[antonien]

Voilà ce qui m'amène...
J'ai importé mes fichiers dans Visual C++ (je les ai développés dans C::B avant de laisser tomber, n'y comprenant rien aux multiples options-réglages-configurations de la bête).
J'ai compilé, sans trop de difficulté, puis généré, avec un peu plus de souci mais on n'a rien sans rien, n'est-ce pas ?
Et voilà t'il pas que monsieur refuse de s'exécuter sous prétexte qu'il ne trouve pas "wxms291ud_core_vc_custom.dll". Je trouve ça particulièrement injuste, voire même diffamatoire parceque ledit "wxms291ud_core_vc_custom.dll" se trouve dans mon répertoire "c:\Visual Studio\wxWidgets-2.9.1\lib\vc_dll"
J'ai déjà truffé ma config de $(WXWIN)\truc et $(WXWIN)\machin : que lui faut il de plus
Où dois-je déclarer les dll appelées par le programme lors de son exécution ?

Merci par avance à mon futur sauveur.

PS : j'ai jeté un oeil dans la FAQ mais je n'ai point trouvé de quoi me consoler.

[antonien]

Bon, ben je vais me créditer une bonne réponse.
En fait, je n'ai pas trouvé la solution en DLL et j'ai tout passé en statique. Et là, hop, ça marche pile-poil.
Je suis mon propre sauveur mais c'est dommage, j'aurais bien aimé comprendre.

[bacelar]

Il semble qu'il vous manque quelques notions de base des dll.

Une dll est une librairie qui est partagée par plusieurs programmes.
Ce n'est pas de la responsabilité du compilateur ni de l'éditeur de lien d'indiquer où elle se trouve dans le système (à part, indirectement avec la notion de version et de Side by Side (SxS) mais c'est une technique "advanced"). Et encore heureux, car cet endroit varie énormément d'un OS à un autre.

Vous ne trouverez donc aucune option dans VS pour la configuration du chargement des dll.
L'éditeur de lien ne fait que donner les points d'entrées (symboles) utilisés dans une dll en ne spécifiant que son nom (de la dll), en aucun cas un éventuel chemin.

C'est le chargeur de l'OS qui déterminer où chercher les dll, lors de l'exécution du programme.

Dans votre cas, le plus simple et de modifier votre variable d'environnement PATH pour que le charger utilise le répertoire "c:\Visual Studio\wxWidgets-2.9.1\lib\vc_dll" lors du chargement de votre programme en mémoire. De manière plus standard, il serait préférable de mettre une copie de cette dll à coté de l'exécutable, car, par défaut, le charger de l'OS commence par le répertoire de travail du programme puis le répertoire contenant le fichier "image" de l’exécutable.

[antonien]

Merci beaucoup, c'est très clair et très instructif. Une dernière question si je peux me permettre. Quand doit on utiliser multithreaded dll plutôt que multithreaded?
Merci par avance

[bacelar]

C'est un peu complexe mais en général, c'est toujours la multithread dll sauf quand des boulets ont eu la riche idée d'utiliser une autre C-Runtime et de faire partager leur superbe trait de génie , en n'isolant pas les mécanismes d'allocation et de désallocation de leurs objets dans leur API de dll, dans leur dll.

Généralement ces deux boulettes vont de pair.

Donc sauf cas très très particulier, c'est multithread dll.

[antonien]

Merci, c'est clair et ça m'évitera les tâtonnements habituels.
Les 3 avantages que je trouve à VC par rapport à C::B-GCC:
- une configuration beaucoup plus accessible à un non spécialiste
- un débugueur nettement plus puissant
- des réponses claires et rapides sur je forum