C++ Girl
  1. C++ Girl
  3. Charger la bibliothèque partagée par chemin au moment de l’exécution
Intereting Posts
Puis-je supprimer un pointeur qui pointe dans un tableau alloué, mais pas au début de celui-ci? Déplacer la sémantique et parfaire la différence de transmission Configuration requirejse pour std :: ignore Mise en œuvre du projet Qt via CMake Une table de transposition peut-elle causer une instabilité de recherche? Essayer de comprendre la procédure de liaison pour écrire un hybride Python / C ++ Erreur PIC lors de la compilation de l’ACE avec Clang Quelle est la durée de vie de boost :: asio :: ip :: tcp :: resolver :: iterator de async_resolve? Erreur avec l’adresse de la fonction membre entre parenthèses Passer la référence de Python à la fonction c ++ encapsulée avec swig pour la valeur de retour Problème concernant l’envoi d’une requête par POCO HTTPSClientSession – échec de la vérification du certificate Cmake ne trouve pas les librairies Boost Faire en sorte qu’une variable de référence de membre copiée se réfère à un membre de la copie et non de l’original Variable statique C ++ et erreur externe non résolue Qu’est-ce que je peux utiliser comme clés std :: map?

Charger la bibliothèque partagée par chemin au moment de l’exécution

Je construis une application Java qui utilise une bibliothèque partagée écrite en C ++ et compilée pour différents systèmes d’exploitation. Le problème est que cette bibliothèque partagée dépend d’une bibliothèque supplémentaire qu’elle trouve normalement sous la variable d’environnement appropriée ( PATH , LIBRARY_PATH ou LD_LIBRARY_PATH ).

Je peux, mais je ne veux pas, définir ces variables d’environnement. Je préfère charger les bibliothèques partagées nécessaires à partir d’un chemin donné au moment de l’exécution, comme un plugin. Et non, je ne veux aucune application de démarrage qui lance un nouveau processus avec un nouvel environnement. Est-ce que quelqu’un sait comment y parvenir?

Je sais que cela doit être possible, car l’une des bibliothèques que j’utilise est capable de charger ses plugins à partir d’un chemin donné. Bien sûr, je préférerais un code indépendant de la plate-forme, mais si cela n’était pas possible, des solutions distinctes pour Windows, Linux et MacOS le feraient également.

EDIT J’aurais dû mentionner que la bibliothèque partagée que je souhaite utiliser est orientée object, ce qui signifie qu’une liaison de fonctions simples ne le fera pas.

    Les systèmes UNIX / Linux que vous pouvez utiliser dlopen . Le problème est alors que vous devez récupérer tous les symboles dont vous avez besoin via dlsym

    Exemple simple: 

     typedef int (*some_func)(char *param); void *myso = dlopen("/path/to/my.so", RTLD_NOW); some_func *func = dlsym(myso, "function_name_to_fetch"); func("foo"); dlclose(myso);

    Va charger le .so et exécuter function_name_to_fetch () à partir de là. Voir la page de manuel dlopen (1) pour plus d’informations.

    Sous Windows, vous pouvez utiliser LoadLibrary et sous Linux, dlopen . Les API sont extrêmement similaires et peuvent charger une so / dll directement en fournissant le chemin complet. Cela fonctionne s’il s’agit d’une dépendance d’exécution (après le chargement, vous “liez” en appelant GetProcAddress / dlsym .)

    Je suis d’accord avec les autres affiches sur l’utilisation de dlopen et de LoadLibrary. Le libltdl vous donne une interface indépendante de la plate-forme pour ces fonctions.

    Je ne pense pas que vous puissiez le faire pour cela.

    La plupart des DLL ont une sorte de fonction init () qui doit être appelée après son chargement, et parfois cette fonction init () a besoin de certains parameters et renvoie un handle à utiliser pour appeler les fonctions de la DLL. Connaissez-vous la définition de la bibliothèque supplémentaire?

    Ensuite, la première bibliothèque ne peut pas simplement regarder si la DLL X est dans la RAM uniquement en utilisant son nom. Celui dont il a besoin peut être dans un répertoire différent ou dans une version / version différente. Le système d’exploitation reconnaîtra la bibliothèque si le chemin complet est identique à un autre déjà chargé et le partagera au lieu de le charger une seconde fois.

    L’autre bibliothèque peut charger ses plugins depuis un autre chemin car elle est écrite pour ne pas dépendre de PATH et ce sont ses propres plugins.

    Avez-vous essayé de mettre à jour les variables d’environnement du processus à partir du code avant de charger la DLL? Cela ne dépend pas d’un processus de démarrage.