Comment utiliser une librarie .so (sous linux)

Bonjour,
J'ai un example d'application C sous windows qui utilise une librarie (DLL).
Avec cette librairie j'ai également reçu un fichier .so et je voudrais tester cette librarie sous Linux.
En gros je voudrais faire la même application que celle que j'ai recu pour windows.
Malheureusement je ne sais pas comment faire pour charger une librairie dans mon code C sous linux.
Ce-dessous vous pouvez voir quelque lignes de codes extraites de l'application C sous windows:

Code:

---

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

//create instance public HINSTANCE myHI;   //definition of callback typedef INT (CALLBACK* LPFNDLLflxSetConfiguration)(int func, int comtype, char *comnr, int comport );   //load lib myHI = LoadLibrary("flxdrv.dll"); . . //register to get callback fron library flxSetConfiguration = (LPFNDLLflxSetConfiguration) GetProcAddress(myHI,"_flxSetConfigurationVB@16"); . . .

---

J'ai essayé d'utiliser ce code sous Linux mais il n'y a pas moyen de compiler.
Pouvez-vous me dire où commencer/quoi changer?
Y a t'il des tutorials où je pourrai trouver plus d'infos sur la manière d'utiliser des libraries C sous Linux et spécialement avec des explications sur les callback?

Merci d'avance pour votre aide.

Alain.

L'API n'est pas la même sous linux.

Il faut que tu regardes du côté de dlopen et cie http://man.developpez.com/man3/dlopen.3.php

sous unixoide tu ne la charges pas...

Elle est dynamique..

Tu dois (par défaut, bien qu'on puisse faire autrement) la placer dans /usr/lib
et uniquement include les ".h", et au moment de la compile indiquer par les flags de compilations où elle se trouve.

Si par défaut elle n'est pas dans /usr/lib, il te faut rajouter :

Code:

---

1 2

-Lchemin

---

ça c'était le principe..

et comme dit Hegros en plus ça compilera pas c'est pas la même API..

Notre ami hiko-seijuro a fait un tutoriel là-dessus :
http://hiko-seijuro.developpez.com/a...que-dynamique/

Certes c'est pour l'exportation de classes C++ (hmmm, c'est quoi le C++ ? :aie:) mais le princpe reste le même pour ce qui est de l'exportation.

Jc

Citation:

---

Envoyé par souviron34

sous unixoide tu ne la charges pas...

---

Si, avec dlopen().

LoadLibrary() <==> dlopen()
GetProcAddress() <==> dlsym()

Citation:

---

Envoyé par David.Schris

Si, avec dlopen().

LoadLibrary() <==> dlopen()
GetProcAddress() <==> dlsym()

---

connais pas.....

Citation:

---

Envoyé par souviron34

connais pas.....

---

Solaris (ou SunOS) et Linux (inspiré de Solaris sur ce point) entre autres. Peut-être pas tous unixoïdes mais

Citation:

---

Envoyé par [url=http://www.die.net/doc/linux/man/man3/dlopen.3.html]man dlopen[/url]

HISTORY
The dlopen interface standard comes from SunOS. That system also has dladdr(), but not dlvsym().
CONFORMING TO
POSIX.1-2001 describes dlclose(), dlerror(), dlopen(), and dlsym().

---

Peut servir, par exemple, pour créer un système de plugins...

Merci beaucoup pour toutes vos réponses.
J'ai lu :

Code:

---

1 2 3

LoadLibrary() <==> dlopen() GetProcAddress() <==> dlsym()

---

Mais je n'arrive toujours pas à utiliser dlsym :oops:
Auriez-vous une idée de comment je dois utiliser la commande dlsym pour faire la même chose que la commande utilisée sous windows(ci dessous)?

Code:

---

1 2	flxSetConfiguration = (LPFNDLLflxSetConfiguration) GetProcAddress(myHI,"_flxSetConfigurationVB@16");

---

Je n'arrive pas à trouver la bonne syntaxe :(

Merci d'avance.

Alain.

Citation:

---

Envoyé par David.Schris

Solaris (ou SunOS) et Linux (inspiré de Solaris sur ce point) entre autres. Peut-être pas tous unixoïdes mais

Peut servir, par exemple, pour créer un système de plugins...

---

ok...

Mais la question de départ étant sur les .so, normalement en C sous unixoide la manière standard de procéder me semble celle que j'ai décrite ( à moins que je sois un vieux crouton.... :cry: ).

La seule différence de principe entre une librairie statique et une librairie dynamque est que le code n'est pas recopié dans le binaire, mais juste les adresses des routines appelées (d'où d'ailleurs l'inconvénient majeur qu'il faut que la bibliothèque soit au même endroit dans le système).

Me trompe-je ?

Citation:

---

Envoyé par souviron34

Mais la question de départ étant sur les .so, normalement en C sous unixoide la manière standard de procéder me semble celle que j'ai décrite

---

La methode que tu decris est la methode implicite, c'est a dire qu'on laisse l'editeur de liens ajouter le code necessaire (dlopen et compagnie) tout seul. Avec gcc, c'est la methode par defaut (i.e. les .so sont preferes aux .a, sauf si -static est precise). Mais il est possible de le faire explicitement, comme indique plus haut.

Citation:

---

Envoyé par philipina

pas à utiliser dlsym

---

Tu peux t'inspirer de cet exemple. Il va chercher explicitement la fonction cos() contenue dans la bibliotheque mathematique.

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 40

#include <stdio.h> #include <stdlib.h> #include <dlfcn.h>   /* * gcc -W -Wall -ansi -pedantic -rdynamic -o so so.c -ldl */   int main(void) { void *handle; int ret = EXIT_FAILURE;   handle = dlopen ("/usr/lib/libm.so", RTLD_LAZY); if (handle == NULL) { fprintf(stderr, "%s\n", dlerror()); } else { double (*cosine)(double); char *error;   cosine = dlsym(handle, "cos"); error = dlerror(); if(error != NULL) { fprintf(stderr, "%s\n", error); } else { printf("%f\n", cosine(2.0)); dlclose(handle); ret = EXIT_SUCCESS; } }   return ret; }

---

Note que le compilateur devrait t'avertir que le C ISO interdit la ligne

Code:

---

1 2	cosine = dlsym(handle, "cos");

---

qui implique un cast de (void *) vers un pointeur de fonction. Mais je n'ai jamais vraiment regarde comment faire sauter cet avertissement...

Citation:

---

Envoyé par DaZumba

qui implique un cast de (void *) vers un pointeur de fonction. Mais je n'ai jamais vraiment regarde comment faire sauter cet avertissement...

---

Tu peux faire le cast suivant (qui marche exclusivement dans ce cas) :

Code:

---

cosine = (double (*)(double)) dlsym(handle, "cos");

---

Citation:

---

Envoyé par DaZumba

Avec gcc, c'est la methode par defaut (i.e. les .so sont preferes aux .a, sauf si -static est precise). .

---

De quel défaut parles-tu ?

C'est la mèthode par défaut si on veut créer des librairies dynamiques, oui peut-être, mais ce n'est pas la méthode par défaut de gcc pour lier... C'est même le contraire..

Quand tu fabriques un éxecutable et que tu précises juste par exemple -lm ou que tu fais appel à stdlib, il ne charge pas une librairie dynamique, mais statique.....

Citation:

---

Envoyé par millie

Tu peux faire le cast suivant (qui marche exclusivement dans ce cas) :

Code:

---

cosine = (double (*)(double)) dlsym(handle, "cos");

---

---

Il n'est encore pas content:

Citation:

---

Envoyé par gcc

ISO C forbids conversion of object pointer to function pointer type.

---

Citation:

---

Envoyé par souviron34

ce n'est pas la méthode par défaut de gcc pour lier...

---

Tu as sans doute raison, je n'arrive pas a trouver une reference pour etayer mon affirmation. Cela parait dependre des plateformes et de la version de gcc...

Citation:

---

Envoyé par souviron34

Quand tu fabriques un éxecutable et que tu précises juste par exemple -lm ou que tu fais appel à stdlib, il ne charge pas une librairie dynamique, mais statique.....

---

Lorsque tu passes l'option -lm à l'éditeur de liens, le code est par défaut lié à une bibliothèque libm.so, qui est donc une bibliothèque partagée, sauf si l'option -static est passée à l'éditeur de liens. Si aucun .so de ce nom n'est disponible, le .a correspondant est chargé. C'est le comportement par défaut sur ma plateforme (debian unstable, gcc 4.1.1 + Ubuntu 6.06, gcc 4.0.3).

Thierry