dlopen et Cie

:salut:

Je doit utiliser une bibliothèque dynamique (sous Unixoïde), j'emploi pour cela les fonction POSIX dlopen, dlsym et dlclose mais je me demandais, y'a pas d'autres technique que ca :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

size_t i = 0; C_List * (* fn_new) (void); void (* fn_free) (C_List ** list); C_List_err (* fn_append) (C_List * list, void * data); void * handle = dlopen ("libclist.so", RTLD_LAZY);     if (handle != NULL) { fn_new = dlsym (handle, "C_List_new"); list = fn_new ();   if (list != NULL) { fn_append = dlsym (handle, "C_List_append");   for (i = 0; i < nblines; i++) { fn_append } }   fn_free = dlsym (handle, "C_List_free"); fn_free (&list); dlclose (handle);

---

... Faire des pointeur de fonctions à outrance, récupérer des fonctions à coup de dlsym ? Bien sûr je ne dois pas utiliser des bibliothèque externe sinon ca sert à rien, c'est dans le cadre d'un petit ensemble de bibliothèques perso qui serviront plus tard dans un plus gros projet, il faut donc que je maîtrise ce côté "dynamique".

Donc ma question est... y'a rien de plus propre ? :aie:


:merci:

Il me manque probablement quelque chose mais pourquoi ne lies-tu pas directement ta bibliothèque dynamique à la compilation de ton programme, plutôt que le faire a posteriori pendant l'exécution (à part pour libérer de la mémoire) ?

Si tu tiens à utiliser dlsym() et cie, tu es obligé de passer par des pointeurs mais, dans le cas des fonctions au moins, une fois déclarés et initialisés, ils s'utilisent comme des fonctions ordinaires.

Ce n'est en effet qu'un petit bout de code et même pas fini mais bien sûr ce n'est pas que pour libérer de la mémoire et je n'utilise pas ma lib que dans ce module mais dans autres futures bibliothèques et dans un futur projet.

Tu peux sans doute au moins te simplifier la vie en rassemblant les pointeurs de fonction dans une structure.

Sinon, comme dit Obsidian, la possibilité de lier les bibliothèques dynamiques automatiquement au chargement existe aussi sous unixoïde, mais je ne sais pas comment on fait.

La possibilité de charger une bibliothèque partagée à la volée est très utile dans la mise en place de p.ex. un système de greffons. Sinon, l'utilisation normale d'une bibliothèque partagée est de lier cette bibliothèque à ton programme à la compilation (en fait à l'édition des liens). Pour ce faire, pas besoin de dlopen() & Cie ni d'utiliser des pointeurs de fonctions.

Ta bibliothèque semble proposer une implantation de liste chaînée. Je ne vois à priori pas l'utilité d'implanter cela sous forme de greffon. Pourquoi veux-tu charger ta bibliothèque dynamiquement dans le contexte présenté?

Avec mes meilleures salutations

Thierry

C'est dans le cadre d'un projet plus vaste qui viendra plus tard mais la liste chaînée sera utilisée par d'autres petites bibliothèques et le programme lui même.

Voici un exemple de micro-bibliothèque partagée sous Linux, si tu veux te faire la main. Une fois compilée, elle s'utilise de la même façon que toutes les autres, dont tu as probablement déjà l'habitude :

Code:

---

1 2 3 4 5 6 7 8

/* ajoute.h */   #ifndef AJOUTE_H #define AJOUTE_H   double ajoute (double,double);   #endif

---

Code:

---

1 2 3 4 5 6 7 8

/* ajoute.c */   #include "ajoute.h"   double ajoute (double x, double y) { return x + y; }

---

Compilation de la bibliothèque :

Code:

---

$ gcc ajoute.c -shared -o ajoute.so

---

Ajout du répertoire local dans la liste des dépôts de bibliothèques (uniquement pour nos tests) :

Code:

---

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

---

Programme utilisant la bibliothèque :

Code:

---

1 2 3 4 5 6 7 8

#include <stdio.h> #include "ajoute.h"   int main (void) { printf ("5 + 8 font %f.\n",ajoute (5,8)); return 0; }

---

Compilation du programme principal :

Code:

---

$ gcc programme.c -shared -o programme

---

Vérification des bibliothèques dont dépend l'exécutable :

Code:

---

1 2 3 4 5

$ ldd programme linux-vdso.so.1 => (0x00007fff263ff000) libajoute.so => ./libajoute.so (0x00007f93f949c000) libc.so.6 => /lib64/libc.so.6 (0x0000003692000000) /lib64/ld-linux-x86-64.so.2 (0x0000003691c00000)

---

Et exécution :

Code:

---

1 2	$ ./programme 5 + 8 font 13.000000.

---

Citation:

---

Envoyé par Franck.H

C'est dans le cadre d'un projet plus vaste qui viendra plus tard mais la liste chaînée sera utilisée par d'autres petites bibliothèques et le programme lui même.

---

OK, mais rien ne t'empêche ici de lier à la compilation. C'est le cas d'utilisation habituel d'une bibliothèque partagée.

Thierry

Ok il suffit donc de lier la bibliothèque au moment de l'édition des liens alors c'est ca ? Mais quelle est alors la raison de l'existence de dlfcn ? Désolé si je me pose des questions existentielles de ce genre mais c'est la première fois que je vais faire et utiliser des bibliothèques dynamiques, en générale je compilais tout ensemble dans les tout petits projets ! :aie:

En gros, les fonctions dl... sont à la liaison à l'édition des liens ce que malloc() est aux variables locales. Ça te permet de le faire explicitement, a posteriori, sur autant de libs que tu le souhaites et ça te permet surtout de les décharger au besoin, ce qui n'est pas négligeable.

C'est aussi une bonne façon de démarrer quand même, en mode dégradé, si une ou plusieurs bibliothèques sont indisponibles.

C'est pratique aussi pour faire un système de plugins pour une application donnée. L'application est compilée à l'avance et les développeurs rajoutent leurs extensions sous forme d'un répertoire de bibliothèques partagées. L'application parcourt alors le répertoire et charge une à une les bibliothèques qu'elle y trouve. Elle peut aussi choisir d'en ignorer certaines…

Ça te permet également d'utiliser la version de la bibliothèque de ton choix, lorsque plusieurs sont disponibles et que les interfaces sont les mêmes. Par extension, cela résout également les cas où deux libs complètement distinctes ont des noms de symboles en commun.

Tu peux aussi mettre en place de cette façon un système de hook si tu veux suivre les appels aux différentes fonctions.

Et d'une manière générale, ça permet de parler au loader, qui joue un rôle non négligeable dans l'exécution des logiciels.

Bon n'étant pas un dieu des scripts Makefile j'ai un petit soucis car C::B que j'utilise normalement m'en fait également, pendant la liaison, C::B me dit qu'il ne trouve pas -lclist alors que le fichier s'appel libclist.so... je pige pas trop !

Sinon à tout hasard voici mon script Makefile:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

CC=gcc CFLAGS=-DLINUX -W -Wall -ansi -pedantic -shared LDFLAGS=-llibcstr.a EXEC=CFile   all: $(EXEC)   c_file: c_file.o main.o $(CC) -o c_file c_file.o main.o $(LDFLAGS)   c_file.o: c_file.c $(CC) -o c_file.o -c c_file.c $(CFLAGS)   main.o: main.c c_file.h c_str.h c_list.h $(CC) -o main.o -c main.c $(CFLAGS)   clean: rm *.o   mrproper: clean rm $(EXEC)

---

Celui-ci me dit:

Code:

---

make: *** Pas de règle pour fabriquer la cible « CFile », nécessaire pour « all ». Arrêt.

---

:aie:

As-tu essayé de passer l'option -L/chemin/vers/bibliotheque à l'édition des liens? Le fichier .so de la bibliothèque doit également figurer dans la variable d'environnement LD_LIBRARY_PATH pour que ton programme fonctionne à l'exécution.

Ainsi LDFLAGS dopit contenir -L/chemin/vers/bibliotheque -lcstr

Plus d'infos ici.

Thierry

Quelques petites erreurs :

— Tu passes « -shared » dans les CFLAGS. Ce flag sert à indiquer que l'on souhaite créer une bibliothèque partagée, et pas en utiliser une. Or, dans les règles concernées, tu écris « -o fichier.o », ce qui ressemble à la création d'un fichier objet ordinaire et qui est en accord avec les autres règles ;

— Le flag « -L » te permet d'indiquer au compilateur une liste de répertoires dans lesquelles il trouvera les bibliothèques partagées nécessaires.

— Make, comme pas mal d'autres choses sous Unix, est case sensitive. « CFile », « cfile », « c_file », etc. sont tous différents. Dans la cible « all » exécutée par défaut — parce qu'elle est en tête de liste — tu passes $(EXEC) en dépendance, et EXEC contient « CFile ». Make va donc chercher un fichier portant ce nom et, à défaut, un règle éponyme pour générer ce fichier nécessaire. Il ne va pas produire un exécutable portant ce nom (et ce n'est pas son rôle).

Salut Franck,

Le chargement dynamique d'une librairie partagée peut être utile dans plein de cas et pas seulement pour des greffons, application généralement citée comme exemple.

Une autre utilisation est l'utilisation d"une librairie tierce de manière portable et indépendante de la version de la dite librairie.

Par exemple, je prend le cas de OCILIB qui supporte une résolution des symboles de la librairie client OCI lors de l'édition des liens ou en runtime à l’exécution.

Pouvoir charger dynamiquement la librairie client d'Oracle me permet d'ajuster le comportement d'OCILIB en fonction de la version d'Oracle (car des dizaines de méthodes sont ajoutées à chaque version). Ce qui permet à OCILIB qui utilise des fonctionnalités Oracle introduites à chaque nouvelles version de s'adapter à la volée à la version dynamiquement chargée.

Et de plus, cela te permet de pouvoir charger différentes version des librairies en question, ce qui n'est pas négligeable...

De plus cela permet d'être compatible avec plus de compilateurs et de simplifier les script de build car tu n'as pas à gérer les différents types de flags, les switch /64bits, etc... propres à chaque compilo car le cc d' AIX n'est pas le même que celui de HP etc....

Donc au final, c'est plus chiant à coder, mais cela t'apporte une indépendance, une souplesse en runtime et un déploiement/build simplifié !

Tu peux aussi faire une bibliothèque statique qui wrappe ce chargement indépendant de la version, comme Windows l'avait fait avec Winsock 2.

Oui en effet, les avantages sont multiples quant au chargement dynamique comme j'ai commencé à faire, je pense que je vais continuer dans cette voie mais juste faire ca plus proprement genre ajouter une fonction _init qui se charge alors en premier, ce qui est garanti par la norme POSIX je pense, peut-être pas du côté dfe Windows... à vérifier. Cette méthode chargera alors les symboles dans une structure contenant les pointeurs de fonctions, structure qui sera donc fournie par mes bibliothèques.

Un chargement dynamique c'est ce que je voulais à la base car le programme qui englobera tout ca et bien d'autres bibliothèques, pourra alors être mis à jour plus facilement et pourquoi même pendant sa propre exécution sauf pour le processus principal peut-être.

Du côté de Windows comment ca se passe pour le chargement dynamique ?

sous windows c'est grosso modo comme sous unix/linux....

Pour OCILIB, j'ai des macros qui me permettent d'avoir un code générique sous toutes les plateformes Windows, Linux et Unices.

Extrait des déclaration des macros

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

#if defined(_AIX) #define LIB_OPEN_FLAGS RTLD_NOW | RTLD_GLOBAL | RTLD_MEMBER #elif defined(__hpux) #define LIB_OPEN_FLAGS BIND_DEFERRED |BIND_VERBOSE| DYNAMIC_PATH #else #define LIB_OPEN_FLAGS RTLD_NOW | RTLD_GLOBAL #endif   #if defined(_WINDOWS)   #include <windows.h>   #define LIB_HANDLE HMODULE #define LIB_OPEN(l) LoadLibraryA(l) #define LIB_CLOSE FreeLibrary #define LIB_SYMBOL(h, s, p, t) p = (t) GetProcAddress(h, s)   #elif defined(__hpux)   #include <dl.h>   #define LIB_HANDLE shl_t #define LIB_OPEN(l) shl_load(l, LIB_OPEN_FLAGS, 0L) #define LIB_CLOSE shl_unload #define LIB_SYMBOL(h, s, p, t) shl_findsym(&h, s, (short) TYPE_PROCEDURE, (void *) &p)   #else   #ifdef HAVE_DLFCN_H #include <dlfcn.h> #endif   #define LIB_HANDLE void * #define LIB_OPEN(l) dlopen(l, LIB_OPEN_FLAGS) #define LIB_CLOSE dlclose #define LIB_SYMBOL(h, s, p, t) p = (t) dlsym(h, s)   #endif

---

Exemple d'utilisation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

/* ... */   LIB_HANDLE handle = LIB_OPEN(path);   LIB_SYMBOL(handle , "SymbolName", SymbolName, SymbolPtr);   /* ... */   LIB_CLOSE(handle);   /* ... */

---

Ouais pas mal ton idée ;)

Si tu veux une fonction appelée au chargement de chaque DLL, pas de problème, il y a DllMain().

Citation:

---

Envoyé par Médinoc

Si tu veux une fonction appelée au chargement de chaque DLL, pas de problème, il y a DllMain().

---

Mouais ca veut quoi... que j'aurais une fonction _init pour les Unixoïdes et DllMain pour Windows, c'est un peu bête deux fonctions qui font en fait la même chose !