Visual Studio 64bits / CMake / jvm.dll / variable path

**Captain'Flam** · 04/09/2015, 16h30

Bonjour,

un probl�me bien complexe m'am�ne vers vous... je vais essayer d'�tre clair :

J'ai du code C bien propre et standard qui peut �tre compil� sous Windows (par Visual Studio 10) et sous Linux (par gcc).
Les fichiers de projets (.sln et .vxproj pour Visual et makefile pour gcc) sont g�n�r�s avec CMake (il y a un beau CMakeLists.txt qui vient avec).
Par ailleurs, depuis le code C, j'invoque du code java qui s'ex�cute via la JNI (et la jvm.dll qui va avec)
Jusque l�, tout va bien...

Nouvelle donne : on veut maintenant faire fonctionner tout �a en 64 bits.

Sous Windows, gr�ce � CMake, il est facile de g�n�rer un projet "Visual Studio 10 Win64".
Donc aucun probl�me pour compiler en 64 bits (apr�s quelques ajustements du code).

Mais l'ex�cution commence directement par l'erreur 0xC000007B (pas tr�s limpide

).

Une petite recherche sur les fora m'apprend que c'est simplement parce qu'il continue � charger la version 32 bits de jvm.dll.
C'est � cause de ma variable path, qui contient un chemin vers elle.
Je la change (ma variable path) et la faisant commencer par le chemin de la version 64 bits (que j'ai install�e) et tout fonctionne !

Le probl�me c'est que je veux pouvoir passer de la version 32 bits � la version 64 bits sans avoir � �diter path � la main.
La solution me semblait �tre d'ajouter un truc du genre "set path=c:\java64;%path%" dans le menu Propri�t�s/Ev�nement de build/Ev�nement post-build/Ligne de commande de Visual.
Malheureusement, �a ne change que le path d'un process temporaire, et pas celui dans lequel va s'ex�cuter mon application...

Et c'est l�, que vous, les experts, entrez en sc�ne !
Y a-t-il un moyen de faire ce que je veux ?
Attention, je ne parle pas de lancer mon application depuis un shell ou un script. Dans ce cas, je modifie mon path depuis le script avant de lancer l'appli.
Je parle bien de lancer l'appli depuis l'environnement de Visual Studio pour pouvoir ex�cuter mon code en pas � pas.

Merci de m'avoir lu jusque l� et d'avance pour vos r�ponses...

**bacelar** · 04/09/2015, 17h58

L'embarra du choix :
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

**Captain'Flam** · 04/09/2015, 19h19

Merci grandement !
Mais ma joie fut de courte dur�e... la solution n'est pas l�...

En effet, jvm.dll se trouve dans une arborescence de dossiers cr��s par l'installateur java.
Elle m�me s'attend � trouver d'autres dll dans cette arborescence.

Donc, m�me si je copie la dll 64 bits � c�t� de l'exe (ce que j'ai fait au d�but), il ira chercher ses d�pendances dans le dossier indiqu� dans $path qui contient la version 32 bits.
Je ne peux pas non plus tout balancer dans le dossier syst�me...

Conclusion, je n'ai pas le choix, le chemin de la dll 64 bits doit �tre dans le path !

**M�dinoc** · 04/09/2015, 21h13

Dans ce cas, � moins de faire un Launcher qui change le path "� la main" programmatiquement, tu peux utiliser la solution suppos�e marcher sous Windows: Installer les deux versions de Java dans Program Files!

La version 32 bits dans C:\Program Files (x86)\Java\blabla, la version 64 bits dans C:\Program Files\Java\blabla, et tu rajoutes C:\Program Files\Java\blabla dans le path une bonne fois pour toutes. La redirection automatique pour les processus 32 bits est cens�e faire le reste.

**Captain'Flam** · 07/09/2015, 11h26

Merci M�dinoc !

En effet, j'avais � faire un launcher, mais il y avait trop de contraintes pour le reste du projet...
(le mode 64bits est une "cerise sur le g�teau" : �a ne doit pas (trop) perturber le projet)

La solution "Program Files" / "Program Files (x86)" est assez tentante (je n'y avais pas pens� du tout) mais pas tr�s portable dans le monde Linux...
En plus, il n'y pas moyen de garantir que toutes les machines auront

Sinon, je pensais � une autre solution : Y a-t-il un moyen d'emp�cher l'exe g�n�r� par Visual de charger les DLL au lancement ?

S'il est possible de ne charger les DLL qu'� la premi�re utilisation (une sorte de mode "lazy"), j'aurais eu le temps de modifier le path...

**M�dinoc** · 07/09/2015, 13h30

Tout-�-fait, il y a une option "delay-loaded DLLs" quelque part dans les options d'�dition de liens.
Et en cas d'�chec, c'est une exception Win32 qui est lev�e lors de la tentative d'appel plut�t qu'une erreur irr�cup�rable qui emp�che le lancement du processus.

**Captain'Flam** · 07/09/2015, 14h33

�a marche !
Cette solution me convient tout � fait...
Dans une fonction dont l'impl�mentation peut �tre d�pendante de l'OS (via de beaux #ifdef), je commence par ajouter le chemin vers la version de jvm.dll qui va bien dans le path.
Du coup, au moment du chargement effectif, il la trouve bien !
Tout est ici et l�.

Merci encore !

**M�dinoc** · 07/09/2015, 16h50

C'est une solution qu'il va falloir que je garde � l'esprit.

**bacelar** · 07/09/2015, 18h48

Le delay-loading peut �tre une solution pour les API variable en fonction de l'OS, mais pour une m�canique 32/64 bits je trouve cela un peu alambiqu�.

J'avais du qu'il y avait l�embarra du choix icic:
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Et en 2 lignes :

Applications can control the location from which a DLL is loaded by specifying a full path or using another mechanism such as a manifest

Bien plus simple que de tripatouiller cette antiquit� qu'est le PATH.

Il y en a bien d'autres de plus adapt�s dans cette m�me page, je trouve.

**M�dinoc** · 08/09/2015, 06h44

Il faut dire que si je me suis un peu int�ress� au SxS non-manag�, je n'ai jamais eu le temps d'aller assez loin pour le faire marcher.
Il en est diff�remment du SxS manag�, o� je me suis justement servi du GAC pour r�soudre des probl�mes de 32/64 bits avec une biblioth�que en C++/CLI.

**Captain'Flam** · 15/09/2015, 09h38

Merci bacelar, je suis bien all� voir la page que tu indiques.
Mais dans mon cas, ce n'est pas applicable :

Applications can control the location from which a DLL is loaded by specifying a full path or using another mechanism such as a manifest.
If SafeDllSearchMode is enabled, the search order is as follows:
1-The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.

Mon appli n'utilise pas de manifest, et je ne peux pas modifier le code � l'endroit o� la dll est charg�e (je ne peux pas changer la string qui contient le chemin vers la dll).
Quant aux autres solutions :
1 : Comme jvm.dll charge elle-m�me toute un collection d'autres dll, cela supposerait de copier toute l'arborescence des libraires java dans le r�pertoire de l'appli... possible, mais tr�s co�teux.
2 : comme 1, mais avec en plus, des droits d'administrateur pour mon appli.
3 : java n'est d�finitivement pas 16 bits.
4 : comme 2.
5 : comme 1.
6 : c'est ma seule solution !
Pour info, j'avais le m�me probl�me avec pthread.dll et libcurl.dll, et je l'ai r�solu avec la solution 1, car ces 2 dll sont autosuffisantes.

**bacelar** · 15/09/2015, 12h07

Mon appli n'utilise pas de manifest,

Pourquoi ne pas profiter de tous ses bienfaits ?

Visual Studio 64bits / CMake / jvm.dll / variable path

Visual C++

Discussions similaires

Partager

Partager