Discussion :

[ChPr]

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 :

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

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

et là, ça fonctionne ???

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

Merci de votre aide.

Pierre

[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

[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

[Invité]

Bonjour,

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

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 :

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

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

[ChPr]

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

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

[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 :

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

[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

[ChPr]

Merci selzig pour cette recherche et ces liens.

Cordialement.

Pierre