liaison dynamique zOS

Question

Je dois créer une bibliothèque liée dynamiquement zOS. Quelles sont les options à transmettre au compilateur.

En outre, comment vérifier si une bibliothèque zOS est lié dynamiquement [dépendant] sur d'autres bibliothèques. nous avons ldd sous Linux, qui montre ce lien. Avons-nous un « ldd » équivalent en terres zOS?

Answer 1

Vous ne dites pas directement, mais je suppose que vous voulez dire un C / C ++ DLL. Vous pouvez faire des bibliothèques partagées dans d'autres langues (même assembleur), mais les étapes seraient différentes.

Tout d'abord, vous devez décider ce que vous voulez exporter. Beaucoup des exemples IBM utilisent la directive ExportAll du compilateur, mais soyez conscient que ceci peut conduire à executables très lent, en fonction de votre style de codage. Si vous ne le faites pas ExportAll, vous aurez besoin #pragma exportation pour quoi que ce soit (code ou données) que vous souhaitez exporter. Ne pas oublier que vous pouvez exporter des données (variables) ainsi que des fonctions exécutables ... parfois vous aurez besoin pour partager des données avec des fonctions DLL.

Ensuite, vous devez définir vos options de compilation sur à la fois client (appelant) et DLL pour utiliser la liaison DLL ... ceci est l'option de compilation -Wc, DLL et lorsqu'elle est activée, elle génère logique supplémentaire dans votre programme pour charger et gérer la DLL. Il est une bonne idée d'inclure également #pragma csect pour vos fonctions exportées si vous pensez que vous aurez jamais la nécessité de mettre à jour la DLL sans le remplacer entièrement.

Lorsque vous liez votre DLL, assurez-vous de spécifier le -Wl, l'option DLL (il y a beaucoup de façons ... cette partie est différente si vous établissez un lien dans le lot - Je suppose que vous construisez dans un fichier make de quelque sorte). Le lien va générer la DLL réelle, ainsi qu'un « passavant » contenant des déclarations « d'importation » pour toutes vos fonctions exportées. Vous en aurez besoin pour relier l'un des programmes côté client que vous attendez d'appeler la DLL. Par exemple, si vos importations sont dans un fichier appelé AAA.x, c89 -Wc, DLL myapp.c AAA.x compilerait le code d'appel, avec la conscience que les fonctions à AAA.x sont éteintes dans une sorte de DLL.

Pour votre point sur les DLL appelant d'autres DLL, ne pas oublier qu'une DLL peut à la fois « servir » et « consommer » des fonctions ... en incluant la plate-forme latérale pour les fonctions dans d'autres DLL, vous pouvez avoir une DLL qui fournit certaines fonctions tout en appelant d'autres DLL à d'autres accès.

La DLL réelle elle-même peut être à plusieurs endroits en fonction de la nature de votre application. Si vous êtes sous Unix convivial, il est juste un exécutable dans LIBPATH. Il peut également être STEPLIB, LNKLST, et ainsi de suite LPA.

Si vous avez besoin, vous pouvez accéder à vos DLL explicitement à l'exécution en utilisant dlopen (), dlsym () et ainsi de suite. En général, cela vous permet de contrôler exactement DLL que vous utilisez (parfois à portée de main si l'utilisateur peut fournir un lui-même), et il vous donne ce qui équivaut à des pointeurs de fonction qui se dénouent dans la DLL.

Il y a d'autres choses de base à considérer lors de la liaison, comme la garantie que votre code est rentrante. La plupart d'entre eux sont précisées dans la documentation IBM, et si vous construisez avec des choses comme « C89 » (ou équivalent), les bonnes options sont généralement configuration automatiquement pour vous (en fait, pour obtenir une bonne idée de ce qui se passe, tour sur la sortie verbeuse et voir tous les paramètres pour vous-même).

Si vous devez construire une référence croisée de ce qui appelle ce que, les services UNIX commande « nm » peut vous donner cette information. Si vous produisez des annonces détaillées édition de liens, toutes les données sont là aussi quand vous construisez vos DLL.

Bonne chance!