[Linux] Utilisation des librairies

Version imprimable

26/05/2011, 12h53
ChPr

[Linux] Utilisation des librairies

Bonjour à toutes et à tous,

Sous Ubuntu 11.04 et Lazarus 0.9.29, j'essaie de mettre en œuvre les exemples donnés au chapitre 12 du Programmer'guide.

Le premier exemple fonctionne bien. J'ai un problème avec celui utilisant une variable procédurale TSubStrFunc : elle plante à la fermeture "dlclose".
Par inadvertance, j'ai doublé l'instruction :

Code:

lib:= dlopen('libsubs.so', 1);

et là, ça fonctionne ???

Avez-vous une expérience de la librairie 'dl' ?

Merci de votre aide.

Pierre
26/05/2011, 18h27
Invité

Bonjour,

J'ai suivi rapidement votre lien. Si j'ai bien compris ce que vous voulez faire, autrefois (en 0.9.28), je passais par une méthode décrite comme exotique mais qui ne m'a pratiquement jamais posé de problèmes... http://www.developpez.net/forums/d92...utilisant-lcl/ (cf l'exemple que je décris).

Aujourd'hui, je préfère placer mes bibliothèques dans des composants... mais si la méthode vous intéresse, je dois posséder encore de vieux codes.

Cordialement. Gilles
26/05/2011, 20h39
ChPr

En suivant votre lien, je vois que les procédures que vous avez utilisées sont faites pour l'environnement Windows. Je les ai déjà utilisées maintes fois avec succès sous DELPHI.

Cette fois, je cherche des méthodes valable à la fois sous Windows et Linux.

Cordialement.

Pierre

Bonjour,

Non, Non, ce code fonctionne sous Windows et Linux... comme il est précisé dans le lien que je vous ai indiqué.

Citation:

Le procédé fonctionne sous Win et Nux. [Pas testé sous Mac]

Sous Nux, évidemment la bibli n'a pas pour extension .dll. Je crois qu'il faut préciser l'extension .so qq part pour l'obtenir (sinon par défaut pas d'extension) lors de la construction. Sous Nux toujours, il faut indiquer le chemin absolu lors de l'appel de la librairie par le programme principal ou alors placer cette dernière en respectant les conventions (de placement de ces fichiers sous linux).
Dans tous les OS, les Strings ne peuvent être échangées sans passer par des pChars.
Enfin pour être aussi exhaustif que possible - il faudrait regarder dans le forum - nous avons rencontré un problème lorsque nous avons utilisé une 0.9.28.2 (à la place de la 0.9.26.2 où nous n'avions pas ce problème) : Plantage lors de l'usage intensif d'une fonction externe. Je ne me souviens plus de ce que nous avons corrigé... mais la procédure de correction a été trouvée par tâtonnements et finalement le hasard nous a été favorable... Peut-être le code ci-dessus est-il le code corrigé.

Et le code de la procédure Destroy de la Form en tient compte pour le déchargement de la librairie.
Code:

1 2 3 4 5 6 7 8 9 10 procedure TForm1.FormDestroy(Sender: TObject); {Déchargement de la librairie et de ses fonctions} begin if (bLibOK=true) then {$IFDEF WIN32} dynlibs.UnLoadLibrary(NilHandle); {$ELSE} dynlibs.UnLoadLibrary(hLib); {$ENDIF} ; end;
Evidemment, ce n'est pas un code typiquement lazarusien. Mais si vous cherchez l'originalité, je vous conseillerais alors plutôt d'utiliser les composants au lieu des librairies dynamiques. Pas de pChars. Pas de fichiers qui traînent ou qui manquent. Possibilité de décomposer le code en sous-units sans avoir à recharger la bibli dans l'éditeur... Faciliter d'accès par complétion... Pas de chargement (Load) de biblis, de déchargement, de déclarations de fonctions... Compilation en même temps que le projet donc pas d'incompatibilité entre la dll compilée avec une version antérieure de Lazarus et le programme qui y fait appel, développé qqs mois plus tard. S'il y a une incompatibilté du composant, elle est détectée au moment de l'installation de celui-ci dans la nouvelle version de Lazarus au moment où vous l'installez. Après c'est la tranquilité assurée. De plus, on peut protéger le code des composants...

Bref, si vous utilisez une librairie dynamique développée par vos soins sous Lazarus, je conseille d'utiliser les composants à la place.

Cordialement. Gilles

27/05/2011, 15h25
ChPr

Citation:

Envoyé par selzig

... Non, Non, ce code fonctionne sous Windows et Linux... comme il est précisé dans le lien que je vous ai indiqué. ...

Je n'avais pas vu l'unité "dynlibs". Apparemment, cette unité permet d'utiliser des librairies *.dll dans l'environnement Linux ?
Pour autant, les librairies que je veux utiliser faisant appels aux fonctions graphiques, les librairies *.dll doivent utiliser le API Windows et je ne suis vraiment pas sûr que ce soit digeste sous Linux ?

Citation:

Envoyé par selzig

... Bref, si vous utilisez une librairie dynamique développée par vos soins sous Lazarus, je conseille d'utiliser les composants à la place. ...

Oui, mais là, je vais utiliser des librairies venant de tierces partie.

Cordialement.

Pierre
27/05/2011, 17h53
Invité

Bonjour,

Il n'est pas possible d'utiliser une xxx.dll sous Linux dans le sens usuel où on l'entend...
On pourrait à la rigueur prendre une librairie écrite pour Linux, la compiler sous Linux et lui donner un nom.dll. On peut donner n'importe quelle extension. En général, on n'en met pas ou on utilise .so... Mais on peut la nommer xxxx.so.14 et faire un lien pour pouvoir "l'appeler" (dans le programme) xxxx.so.

Si vous utilisez une librairie provenant de l'extérieur dont vous ne possédez pas le source alors le problème se pose différemment. On utilise les techniques classiques d'accès aux bibliothèques comme par exemple l'accès aux bibliothèques C (et uniquement C - pas C++). Mais, il faut que la bibliothèque soit compilée dans l'OS que vous utilisez. Si vous utilisez les API Windows... cela ne fonctionnera qu'en Windows...

Et désolé d'avoir mal compris votre question. Votre lien précisait :

Citation:

Programming shared libraries
12.1 Introduction
12.2 Creating a library
12.3 Using a library in a pascal program
12.4 Using a pascal library from a C program
12.5 Some Windows issues

J'ai pensé que la librairie et que le programme l'appelant était lazarusien.

Je rectifie donc le "tir" en vous proposant un lien intéressant que m'avait fourni Batyann811 sur ce forum en juin 2010.
Cordialement. Gilles
27/05/2011, 19h17
ChPr

Citation:

Envoyé par selzig

... Si vous utilisez une librairie provenant de l'extérieur ... il faut que la bibliothèque soit compilée dans l'OS que vous utilisez. ...

Normalement, les bibliothèques que je vais essayer d'employer (GStreamer) sont compilées pour les environnements Windows, Linux, MacOs, ... Ça ne devrait donc pas poser de problème.

Merci pour le lien C --> Pascal.

Cordialement.

PierreC
28/05/2011, 00h02
ChPr
Dans mon programme de test écrit avec Lazarus 0.9.29 sous Ubuntu 11.04, je m'interface avec deux librairies :
- l'une écrite en C : ça marche très bien,
- l'autre écrite via Lazarus 0.9.29 : les fonctions internes de la librairie marchent, mais quand je clique sur le bouton de fermeture du programme, tout se fige , le programme ne s'arrête pas.
Le problème ne vient de la librairie en C car si je la supprime, le problème est le même.
Si je supprime tout le contenu de ma librairie écrite via Lazarus, le problème est le même. Apparemment, c'est le simple fait de charger cette librairie (via dlopen) qui crée le problème.

NOTA : le même programme et la même librairie ne posent pas de problème sous Windows !

Avez-vous une idée de ce qui se passe ?

Merci de votre aide.

Pierre
28/05/2011, 11h30
Invité

Bonjour,

Le bugtracker fait état d'un problème découvert récemment avec dlOpen en Linux 64. Peut-être votre PC est-il un 64 bits ?... ou le problème ne se limite-t-il pas au 64 mais également au 32.

En attendant, "faute de mieux", vu qu'il s'agit d'une librairie lazarusienne, vous pouvez probablement contourner le problème avec DynLibs:D.

Cordialement. Gilles

Citation:

Envoyé par selzig

...En attendant, "faute de mieux", vu qu'il s'agit d'une librairie lazarusienne, vous pouvez probablement contourner le problème avec DynLibs ...

Malheureusement, cette unité ne règle rien car, en interne, elle va chercher les fonctions de bibliothèques propres à chaque système. En l'occurrence, pour Linux, elle appelle : dlopen, dlsym et dlclose.

Elle est seulement utile à avoir qu'un seul type d'écriture quel que soit l'OS utilisé, ce qui est déjà pas mal.

Je peux penser que c'est ma librairie qui est foireuse, que je n'utilise pas les bonnes options de compilation, que sais-je encore ...

Donc, si une bonne âme voulait bien me construire (réaliser le fichier "libsubs.so") et me le mettre en fichier joint à partir d'une librairie appelée "subs" contenant les deux fonctions suivantes :
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 function Anagramme(Txt: PChar): PChar; cdecl; var i, Length: Integer; Temp: string; begin Length:= StrLen(Txt); Temp:= Txt; for i:= 1 to Length do Temp[i]:= Txt[Length-i]; Anagramme:= PChar(Temp); end; function SubStr(CString: PChar; FromPos, ToPos: LongInt): PChar; cdecl; var Length: Integer; begin Length:= StrLen(CString); SubStr:= CString+Length; if (FromPos > 0) and (ToPos >= FromPos) then begin if Length >= FromPos then SubStr:= CString+FromPos-1; if Length > ToPos then CString[ToPos]:= #0; end; end; exports Anagramme, SubStr;
Parce que là je ne sais plus quoi faire !

Cordialement

Pierre

Je viens d'essayer et ça marche.

La bibliothèque 'Subs.pp' :

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
library Subs;
{$mode objfpc}{$h+}
 
function Anagramme(Txt: PChar): PChar; cdecl;
var
  i, Length: Integer;
  Temp: string;
begin
  Length:= StrLen(Txt);
  Temp:= Txt;
  for i:= 1 to Length do
    Temp[i]:= Txt[Length-i];
  Anagramme:= PChar(Temp);
end;
 
function SubStr(CString: PChar; FromPos, ToPos: LongInt): PChar; cdecl;
var
  Length: Integer;
begin
  Length:= StrLen(CString);
  SubStr:= CString+Length;
  if (FromPos > 0) and (ToPos >= FromPos) then
   begin
     if Length >= FromPos then
       SubStr:= CString+FromPos-1;
     if Length > ToPos then
       CString[ToPos]:= #0;
   end;
end;
 
exports
  SubStr, Anagramme;
end.

Le programme 'TestSubs.pas' :

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
program TestSubs;
 
{$mode fpc}{$h+}
 
type
  TSubStrFunc = function(const CString:PChar;FromPos,ToPos: longint):PChar;cdecl;
  TAnagrammeFunc = function(Txt: PChar): PChar; cdecl;
 
function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl';
function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl';
function dlclose(lib: pointer):longint;cdecl;external 'dl'; 
 
var
  s: PChar;
  FromPos, ToPos: Integer;
  lib : pointer;
  SubStr : TSubStrFunc;   
  Anagramme : TAnagrammeFunc;
begin
  lib := dlopen('libSubs.so',1);
  if lib = nil then
  begin
    WriteLn('libSubs.so introuvable !');
    Halt(1);
  end;
 
  Pointer(Substr):=dlsym(lib,'SubStr'); 
  Pointer(Anagramme) := dlsym(lib, 'Anagramme');
 
  s := 'Test';
  FromPos := 2;
  ToPos := 3;
  WriteLn(SubStr(s, FromPos, ToPos));
 
  s := 'pascal';
  WriteLn(Anagramme(s));
 
  dlclose(lib);
end.

Pour la compilation (j'ai fait ça en ligne de commande mais ça doit marcher sous lazarus) :

Code:

1
2
3
 
fpc Subs.pp
fpc TestSubs.pas

Pour executer :

Code:

LD_LIBRARY_PATH=. ./TestSubs

"LD_LIBRARY_PATH=." c'est pour ajouter le répertoire courant (.) au chemin de recherche des bibliothèque dynamique. Ça évite de copier la bibliothèque dans /lib ou /usr/lib.

29/05/2011, 11h02
ChPr

Merci batyann811 pour cette réponse.

J'avais oublié de dire que l'appication tournait dans le mode graphique et non pas en mode console.

Effectivement en mode console, chez moi, ça marche sous Windows et Linux. En mode graphique, ça marche sous Windows, mais pas sous Linux.

Par ailleurs, le code complet de la librairie que vous me montrez est strictement le même que celui que j'ai écrit. Seules les options de compilation peuvent faire que le résultat est différent et c'est la raison pour laquelle j'avais sollicité qu'on me fasse parvenir en fichier joint le résultat de la compilation.

D'autre part, je n'ai jamais réussi à mettre en œuvre LD_LIBRARY_PATH= .Ce n'ai pas grave, pour l'instant j'ai contourné ce problème. Mais je ré-essayerai.

Merci de votre aide.

Pierre

Bonjour Pierre,

Je viens de tester le code de Batyann811 sur une "vieille" 0.9.29. fpc 2.4.1 sous Ubuntu 10.04 LTS [32]. Cela semble fonctionner correctement.
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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 unit uMain; {$mode objfpc}{$H+} interface uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, dl; type TSubStrFunc = function(const CString:PChar;FromPos,ToPos: longint):PChar;cdecl; TAnagrammeFunc = function(Txt: PChar): PChar; cdecl; { TForm1 } TForm1 = class(TForm) procedure FormShow(Sender: TObject); private { private declarations } public { public declarations } end; function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl'; function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl'; function dlclose(lib: pointer):longint;cdecl;external 'dl'; var Form1: TForm1; HandleLib : Integer; implementation {$R *.lfm} var s: PChar; FromPos, ToPos: Integer; lib : pointer; SubStr : TSubStrFunc; Anagramme : TAnagrammeFunc; { TForm1 } procedure TForm1.FormShow(Sender: TObject); begin lib := dlopen(pchar(IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName))+'Subs.so'),1); if lib = nil then begin Showmessage('libSubs.so introuvable !'); Halt(1); end; Pointer(Substr):=dlsym(lib,'SubStr'); Pointer(Anagramme) := dlsym(lib, 'Anagramme'); s := 'Test'; FromPos := 2; ToPos := 3; Showmessage(SubStr(s, FromPos, ToPos)); s := 'pascal'; Showmessage(Anagramme(s)); dlclose(lib); end; end.
Seule petite différence : La procédure d'appel dlopen. Cela remonte à une vieille discussion avec Batyann811 : http://www.developpez.net/forums/d93...-poste-client/ [Dans votre cas, on pourrait s'en passer. Mais quand par exemple, un poste client utilise déjà le lien libmysql avec une version incompatible de mySQL - la modification du codage interne des passwords entre la version 4 et la 5-, il est pratique de pouvoir placer sa libmysql à l'endroit choisi et de fournir strictement les dépendances nécessaires].

Ceci dit, d'une SVN à l'autre de Lazarus, on rencontre parfois des problèmes... et surtout d'une version d'Ubuntu à l'autre. Les développeurs d'Ubuntu sont prolifiques et s'embarassent peu des compatibiltés ascendantes. Ceci explique certainement cela... et le fait que les développeurs de Lazarus soient à la peine.

J'ai placé un zip du répertoire Nux dans lequel j'ai testé les sources de cette discussion. Il contient également les fichiers compilés (TestSubs et Subs.so). Le tout est à cette adresse. (Ne pas oublier de redonner les droits nécessaires après décompression et de déclarer TestSubs comme exécutable).

Bonne fin de WE.
Cordialement. Gilles

29/05/2011, 18h52
ChPr

Bonsoir selzig,

Un grand merci pour les fichiers que tu m'a envoyés.

J'ai remplacé purement et simplement ma librairie par la tienne "Subs.so" que j'ai renommée en "libsubs.so".

j'ai lancé mon programme et ... ça a marché : plus de plantage à la fermeture.

Ensuite, j'ai repris le source de ta librairie "Subs.lpi" et "Subs.lpr" et je l'ai compilé avec mon Lazarus 0.9.29 : j'ai retrouvé mon plantage. Vu le contenu de ton fichier "Subs.lpi", apparemment, tu as Lazarus 0.9.27, non ? Quelle version de fpc as-tu ? moi, j'ai la version 2.4.2.

Par ailleurs, Lazarus est un IDE utilisant fpc et son compilateur. S'il y a bug, je pense que cela vient plutôt du compilateur que Lazarus lui-même. Qu'en penses-tu ?

Cordialement.

Pierre.
30/05/2011, 08h46
Invité

Bonjour,

La version utilisée est une Lazarus 0.9.29-26289 avec un fpc 2.4.1, tous deux récupérés par svn...

Citation:

Envoyé par ChPr

Par ailleurs, Lazarus est un IDE utilisant fpc et son compilateur. S'il y a bug, je pense que cela vient plutôt du compilateur que Lazarus lui-même. Qu'en penses-tu ?

En réalité, sur l'ensemble des bugs que j'ai rencontrés, FP est rarement directement en cause. J'ai souvent plus de mal avec la LCL. Mais dans ce cas précis, je n'ai aucune idée. Je dois installer dans la semaine une svn lazarus-fpc sur une nouvelle Ubuntu dont je n'ai pas fait le choix encore. La 10.04.LTS me convient très bien. Je ne sais pas ce que vaut la 11.04. Si j'arrive à reproduire le bug, je pourrai peut-être formuler une ébauche d'avis sur la question.

Cordialement. Gilles
30/05/2011, 13h30
ChPr

Citation:

Envoyé par selzig

... La version utilisée est une Lazarus 0.9.29-26289 avec un fpc 2.4.1, tous deux récupérés par svn...

Suite à la mise à jour vers la version 0.9.30, la version de fpc étant toujours la 2.4.2, j'ai toujours le problème.

J'ai envie d'envoyer un rapport de bug, qu'en pensez-vous ?

Cordialement.

Pierre
31/05/2011, 11h13
Invité

Bonjour Pierre,

11H15
J'ai essayé ce matin sur mon portable sur lequel sont installés lazarus_0.9.31.29158-0_i386.deb, fpc_2.4.3-110122_i386.deb et fpc-src_2.4.3-110122_i386.deb. Le bug est bien présent. Sur le bug tracker, hormis le problème signalé en Linux 64 bits, je n'ai rien vu d'autre... mais le système de recherche n'est pas performant (ou je ne l'ai pas découvert). A mon avis, cela mérite quand même une "petite déclaration".

16H50
Je viens d'installer la svn du jour sur Ubuntu 10.04 : Lazarus 0.9.31 + fpc 2.4.5. Le code fonctionne correctement. Donc le bug n'existe plus...
Dossier zippé du programme et de sa librairie (compilés avec cette version) ... et les .deb d'installation Lazarus/fpc (Linux 32), à cette adresse.

Cordialement. Gilles
02/06/2011, 20h59
ChPr

Merci selzig pour cette recherche et ces liens.

Cordialement.

Pierre