Comprendre la construction et le chargement de dll extension lua dans un environnement lua intégré lié statiquement

J’ai un environnement lua relativement complexe et j’essaie de comprendre comment les éléments suivants pourraient / pourraient fonctionner. La configuration de départ comprend les deux modules suivants:

  • Application principale (pas d’environnement lua)
  • DLL (lié statiquement à lua lib, interprète compris)

La dll est chargée dans l’application principale et exécute un interpréteur de console lua et une API lua accessible à partir de la console.

Maintenant, disons que je veux étendre cette configuration pour inclure une autre dll qui étendrait cette API lua, luasql par exemple. La nouvelle dll doit être liée à lua pour pouvoir être créée, et je crois comprendre que je ne peux pas lier statiquement à lua car il y aurait maintenant deux copies non partagées du code lua en cours de traitement lorsque je chargerai la DLL d’extension. Cependant, même si je construisais la librairie lua core en tant que dll et que je la liais à l’extension dll, cette DLL lua core ne serait pas chargée au moment de l’exécution par l’application principale ou la dll principale. Donc mes questions sont:

  1. Que se passe-t-il si je charge cette dll d’extension à partir de l’interprète lua dans la dll primaire, en considérant que la dll lua core ne sera pas chargée?
  2. Si je chargeais la DLL lua core à l’exécution, comment cela pourrait-il entrer en conflit avec la lib Lua liée de manière statique?
  3. Est-ce que les deux scénarios (lier statiquement dans l’extension DLL et lier / charger dynamicment la lua dll) aboutiraient à avoir deux copies du code kernel lua en cours?
  4. Dans ce cas, que se passerait-il si j’essayais d’appeler une fonction API à partir de l’environnement / interpréteur Lua de la DLL principale qui était construit / chargé dans la DLL d’extension?
  5. OU lua dispose-t-il d’une sorte de mécanisme spécial pour charger les DLL natives fournissant de nouvelles fonctions d’API C qui lui permet de contourner les règles de liaison normales?

J’espère que j’ai fourni suffisamment de détails pour rendre les questions spécifiques, sinon je me ferai un plaisir d’affiner le scénario / les questions.

Edit: J’ai examiné la possibilité de regrouper des bibliothèques Lua supplémentaires pour une exécution Lua incorporée et liée statiquement. Je pense que cela peut être utile pour fournir une solution en bout de ligne, mais j’aimerais le comprendre au niveau de l’éditeur de liens.

Vous ne pouvez pas avoir la situation lorsque vous chargez un interprète (disons qu’il est lié statiquement) et que vous chargez un module X lié à une dll avec un interpréteur Lua, qui charge une autre copie de l’interprète. Cela est susceptible de provoquer un blocage de l’application. Vous devez faire en sorte que la dll chargée utilise l’interpréteur déjà chargé, soit en établissant un lien avec cette dll avec l’interpréteur, soit en utilisant une dll proxy (voir ci-dessous).

Vous avez deux options principales: (1) créer dllA qui est chargé par l’application principale qui dépend de Lua dll; vous pouvez ensuite lier tous les autres modules lua à Lua dll sans aucun problème; ou (2) inclure Lua dll dans dllA, mais exposer les méthodes Lua afin que les modules lua puissent être liés à cette dllA.

Je pense que la première option est beaucoup plus simple et ne nécessitera probablement aucune modification des modules de Lua (tant que vous pouvez conserver le nom de la dll Lua identique à celui sur lequel les modules sont compilés).

Une autre option que je devrais mentionner est que vous pouvez toujours utiliser les modules Lua compilés avec une DLL Lua même avec des applications ayant un interpréteur Lua compilé de manière statique. Vous devez utiliser une DLL proxy . voir ce fil de discussion pour la solution et la discussion correspondante.

La réponse se résume à ceci:

  1. N’essayez pas de charger des extensions Lua à partir d’une DLL liée à un Lua-core différent. Cela causerait un chaos total.
  2. Tant que toute extension Lua chargée résout toutes ses dépendances avec le kernel Lua approprié, peu importe (à part le gonflement) le nombre de cœurs Lua que vous utilisez.

Gardez à l’esprit que Windows résout toujours les symboles en fonction de leur nom et de leur DLL.