Discussion :

[philipina]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[hegros]

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

[souviron34]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  -Lchemin

ça c'était le principe..

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

[fearyourself]

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++ ? ) mais le princpe reste le même pour ce qui est de l'exportation.

Jc

[David.Schris]

sous unixoide tu ne la charges pas...

Si, avec dlopen().

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

[souviron34]

Si, avec dlopen().

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

connais pas.....

[David.Schris]

connais pas.....

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

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...

[philipina]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
LoadLibrary() <==> dlopen()
GetProcAddress() <==> dlsym()

Mais je n'arrive toujours pas à utiliser dlsym
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Je n'arrive pas à trouver la bonne syntaxe

Merci d'avance.

Alain.

[souviron34]

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.... ).

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 ?

[DaZumba]

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.

[DaZumba]

pas à utiliser dlsym

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[millie]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[souviron34]

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.....

[DaZumba]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Il n'est encore pas content:

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

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...

[Thierry Chappuis]

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