Discussion :

[Captain'Flam]

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]

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

[Captain'Flam]

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]

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]

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]

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]

Ç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]

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

[bacelar]

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]

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]

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]

Mon appli n'utilise pas de manifest,

Pourquoi ne pas profiter de tous ses bienfaits ?