Discussion :

[sandul]

Bonjour,

Je viens du monde Java et mes connaissances C++ sont limitées: ce que j'avais appris en fac, loooong time ago + quelques projets de petite envergure...

J'hérite donc d'un projet important C++ (une dll) et j'accède à cette dll depuis Java (via JNI). Le projet C++ initial a été créé sous VS 6 et je l'ai porté sous VS 2008. Jusque là tout baigne.

En forçant une exception C++ à des fins de test, je retrouve dans le dump Java ceci:
...
0x00400000 - 0x00423000 C:\bin\java\bin\java.exe
0x7c920000 - 0x7c9e6000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c912000 C:\WINDOWS\system32\kernel32.dll
0x77d70000 - 0x77e1d000 C:\WINDOWS\system32\ADVAPI32.dll
0x77c20000 - 0x77cbf000 C:\WINDOWS\system32\RPCRT4.dll
0x76f00000 - 0x76f13000 C:\WINDOWS\system32\Secur32.dll
0x7c340000 - 0x7c396000 C:\bin\java\jre\bin\msvcr71.dll
0x6d870000 - 0x6dac0000 C:\bin\java\jre\bin\client\jvm.dll
0x77f30000 - 0x77fc1000 C:\WINDOWS\system32\USER32.dll
0x77bd0000 - 0x77c18000 C:\WINDOWS\system32\GDI32.dll
0x76a50000 - 0x76a7f000 C:\WINDOWS\system32\WINMM.dll
0x6d320000 - 0x6d328000 C:\bin\java\jre\bin\hpi.dll
0x76b20000 - 0x76b2b000 C:\WINDOWS\system32\PSAPI.DLL
0x6d820000 - 0x6d82c000 C:\bin\java\jre\bin\verify.dll
0x6d3c0000 - 0x6d3df000 C:\bin\java\jre\bin\java.dll
0x6d860000 - 0x6d86f000 C:\bin\java\jre\bin\zip.dll
0x10000000 - 0x10430000 C:\tmp\trial\MyDLL.dll
0x71a80000 - 0x71a8a000 C:\WINDOWS\system32\WSOCK32.dll
0x71ad0000 - 0x71ae7000 C:\WINDOWS\system32\WS2_32.dll
0x77b70000 - 0x77bca000 C:\WINDOWS\system32\msvcrt.dll
0x71ac0000 - 0x71ac8000 C:\WINDOWS\system32\WS2HELP.dll
0x775c0000 - 0x7764b000 C:\WINDOWS\system32\OLEAUT32.dll
0x77480000 - 0x775b9000 C:\WINDOWS\system32\ole32.dll
0x78480000 - 0x7850d000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCP90.dll
0x78520000 - 0x785c3000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCR90.dll
....

Ce sont surtout les deux dernières DLL qui m'inquiètent, car situées dans WinSxs. La trace d'erreur est obtenue sur une machine 2K3 server sur laquelle j'avais recompilé le projet C++ et les deux DLL existent bel et bien dans WinSxS sur cette machine. Mais j'ai fait un test simple: j'ai copié dans le path les 2 DLL runtime et par la suite j'ai mis à la Corbeille le contenu du répertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\ . A l'exécution, il y a un message d'erreur, comme quoi il ne trouve pas les bibliothèques nécessaires.

Deux questions:

1. Comment puis-je me débarasser du nom EN DUR dans ma DLL (à savoir, C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375\MSVCP90.dll) et pouvoir mettre une copie de MSVCP90.dll dans le path (à côté de ma DLL que j'appelle depuis Java) ?

2. J'ai également constaté que à chaque fois que je refais un build de la DLL sous C++, VS 2008 me crée un nouveau répertoire sous C:\WINDOWS\WinSxS\ avec les deux DLL dedans (en fait il y en a une 3ème, toujours un runtime). Y a-t-il un moyen d'empêcher ce fonctionnement (car avec mon expérience C++ je vais compiler des centaines de fois et je pense à l'espace disque :-D :-D)

D'avance un grand merci.

[Médinoc]

1. Le chemin n'est pas codé en dur. Les DLLs font partie d'un Assembly identifié par ses nom, processeur, version et hash.
   Si tu veux fournir les DLL à côté du programme, tu dois copier l'assembly complet, les DLLs et leur manifeste:
   
   • MSVCR90.DLL
   • MSVCP90.DLL
   • MSVCM90.DLL
   • Microsoft.VC90.CRT.manifest
2. Je n'ai jamais eu ce comportement avec VS 2005: Chez moi, il y a juste un certain nombre de dossiers Microsoft.VC80.CRT, et ce nombre ne varie pas avec les recompilations.
   Je ne sais pas pourquoi ton 2008 fait ça (ou a l'air de faire ça), mais WinSxS étant le Global Assembly Cache, il a peut-être une limite de taille de toute façon...

[sandul]

Merci pour la réponse.
Tu dis: "Le chemin n'est pas codé en dur", mais comment sait-il chercher dans le répertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375? Il n'est pas dans le path.

J'ai essayé avec ce que tu proposes (fichier manifest):
a- j'en ai trouvé un dans c:\program files\microsoft visual studio 9.0\vc\redist\x86\Microsoft.VC90.CRT et
b- je l'ai recopié à côté des 3 dll runtime et de ma dll.

Le dump reste le même (à savoir, toujours les DLL dans le répertoire XsX qui sont chargées et pas leurs copies). J'ai également essayé de modifier le nom du manifest en le rebaptisant MyDLL.manifest (pour avoir le même nom que mon DLL, il me semble avoir lu ceci une fois, mais je crois que cela était pour les .exe) avec le même résultat.

Faut-il bidouiller les options Manifest Tool dans les propriétés du projet de création de DLL?

Encore merci

[sandul]

En recherchant un peu (ex http://cpp.developpez.com/faq/vc/ind...VC2005VCRedist) je retrouve

"Si on ne veut pas distribuer de DLL ,il faudra lier statiquement les MFC et sélectionner dans l'onglet C++ / option génération de code / bibliothèque runtime :Multithread (/MT)".

Le souci, c'est que le projet dll s'appuie sur un autre projet pour créer un .lib (option de compilation: /MD) qui à son tour fait appel à des composants achetés sans code source mais complilés à leur tour avec VS 2008 et avec la même option (/MD). Je crois que l'option /MT n'est pas un choix valide dans mon cas, non?

[farscape]

salut,
il ne vaut mieux pas ...

Si on ne veut pas distribuer de DLL ,il faudra lier statiquement les MFC et sélectionner dans l'onglet C++ / option génération de code / bibliothèque runtime :Multithread (/MT)
Néanmoins il faudra veiller à ne pas mélanger les modes de fonctionnement avec la CRT en Multithread DLL et statique, pour éviter les problèmes sur les libérations d'objets entre modules ou partage de ressources fichiers.

[Médinoc]

Merci pour la réponse.
Tu dis: "Le chemin n'est pas codé en dur", mais comment sait-il chercher dans le répertoire C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_D08D0375? Il n'est pas dans le path.

Comme je l'ai déjà dit, WinSxS est un dossier spécial (le Global Assembly Cache). Windows sait naturellement où il se trouve, donc si un assembly est dans le GAC, Windows le trouvera.

J'ai essayé avec ce que tu proposes (fichier manifest):
a- j'en ai trouvé un dans c:\program files\microsoft visual studio 9.0\vc\redist\x86\Microsoft.VC90.CRT et
b- je l'ai recopié à côté des 3 dll runtime et de ma dll.

Le dump reste le même (à savoir, toujours les DLL dans le répertoire XsX qui sont chargées et pas leurs copies). J'ai également essayé de modifier le nom du manifest en le rebaptisant MyDLL.manifest (pour avoir le même nom que mon DLL, il me semble avoir lu ceci une fois, mais je crois que cela était pour les .exe) avec le même résultat.

Sur un PC où le runtime est dans le GAC, c'est normal que Windows prenne celui du GAC puisse que c'est la même version. Par contre, un programme joint aux DLLs et au manifeste devrait fonctionner sur un poste où le Paquetage Redistribuable de Visual 2008 n'est pas installé.

[sandul]

Merci beaucoup, Médinoc. Effectivement, sur une autre machine ça marche avec les dll de runtime + le manifeste.

J'ai maintenant un autre souci:
Lorsque je dis "ça marche" cela signifie que le programme se lance, il y a le premier appel natif depuis Java, côté C++ je peux voir dans la console des messages qui m'appartiennent, mais ça plante vite-fait.

Sur la machine avec VS2008 ça plante aussi, mais autrement. Plus exactement, je n'ai pas réussi à avoir un plantage durant tout une batterie de tests (durant des heures). Les tests comportent la création d'un wrapper Java pour une classe C++ et beaucoup beaucoup d'appels natifs par la suite. Si je fais, à la fin, la destruction de l'objet (un delete() sur le wrapper) et je le recrée durant le même jeu de tests j'arrive à un moment donné à faire planter l'appli depuis la machine VS2008 aussi avec un siginfo d'essai de lecture d'une basse adresse (0x000000004). Cette machine plante donc aussi, mais elle est bien plus robuste que les autres machines (sans VS2008 installé ==> j'ai testé 3 autres machines et le résultat est le même, à savoir plantage IMMEDIAT sur le premier constructeur C++ après l'écriture de quelques lignes de debug)

Il y a donc quelque chose qui cloche dans la partie C++, mais le souci est que les tests effectués uniquement à partir de C++ ne permettent pas de mettre en évidence cette anomalie. Est-ce que vous avez une idée concernant les possibilités d'isoler l'anomalie? Des outils existants? Ou n'importe quelle suggestion? Car passer au peigne fin le projet C++ (qui fait presque 2 Mo de code source + des bibliothèques tierce dont je n'ai pas le code) est une option que j'ai déjà écartée...

Encore un grand merci

[Médinoc]

Je me demande si tu n'essaies pas de détruire dans une DLL (voire l'exe de la JVM) un truc que tu as alloué dans une autre...