Discussion :

[e-ric]

Salut à tous

Ceci s'adresse aux utilisateurs de Debian (Jessie) ou autre distribution Gnu/Linux qui aurait le même problème.

J'ai eu quelques soucis en installant le paquet sqlite3laz.0.4 depuis l'EDI de Lazarus, une erreur générique de liaison survenant à chaque fois. J'ai eu le même problème lors de l'installation des composants Zeos dans la version 1.6 de Lazarus.

La bonne nouvelle est que j'ai trouvé l'origine du problème, il s'agit bêtement du nom de la bibliothèque pour SQLite3 qui diffère entre le source du composant sqlite3.inc et les noms de fichiers (ou liens) disponible dans le système, le code du composant attend libsqlite3.so et mon système ne dispose que de libsqlite3.so.0.8.6 (bibliothèque) et libsqlite3.so.0 (lien symbolique). Je ne sais pas s'il s'agit d'une erreur dans le composant ou d'une des différences subtiles inter-distribution.

La solution à mon avis la plus simple et la moins risquée consiste à créer un lien symbolique avec le nom attendu dans le source du composant, soit :

Code bash :

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

ln -s libsqlite3.so.0 libsqlite3.so

Cela permet de rester dans le cadre de la distribution sans dépendre du numéro de version réelle de la bibliothèque binaire.

Et l'installation de la Zeos se déroule bien comme par enchantement.

J'en ai profité pour ajouter un petit paragraphe dans le Wiki de Lazarus http://wiki.freepascal.org/SQLite/fr..._Debian_Jessie.

Cdlt

[Jipété]

Salut,

La solution à mon avis la plus simple et la moins risquée consiste à créer un lien symbolique avec le nom attendu dans le source du composant, soit :

Code bash :

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

ln -s libsqlite3.so.0 libsqlite3.so

Cela permet de rester dans le cadre de la distribution sans dépendre du numéro de version réelle de la bibliothèque binaire.

Bien joué

Tu as juste oublié de bien préciser que cette commande doit être exécutée en étant positionné dans le dossier contenant le binaire dont tu veux créer un raccourci au nom... raccourci,
(chez moi dans ma vieille Debian 32 bits, le chemin en question est /usr/lib/i386-linux-gnu/)
C'est un grand classique cette histoire.

[e-ric]

Tu as juste oublié de bien préciser que cette commande doit être exécutée en étant positionné dans le dossier contenant le binaire dont tu veux créer un raccourci au nom... raccourci,

Si on veut, vu que les chemins n'étaient pas explicitement précisés... Il est vrai que l'emplacement n'est pas un grand connu du public mais je l'ai précisé dans le Wiki.

J'en profite pour rappeler que j'ai traduit un grand nombre de pages dans le Wiki (ce qui représente un grand nombre d'heures passées), les volontaires pour relire/corriger/compléter sont les bienvenus. Il suffit de rechercher les contributions de e-ric (toujours le même ). Je remercie par avance les bonnes âmes qui le feront, cela profitera à tous et augmentera l'intérêt de cet EDI.

C'est un grand classique cette histoire.

Oui mais comme toujours, on y pense pas toujours du premier coup. Pour les composants Zeos, j'ai perdu un temps fou là-dessus, je suis donc très content d'avoir abouti.

En espérant que cela évite des pertes de temps à d'autres ...

Cdlt

[mm_71]

Dans ce fil de discussion:

https://www.developpez.net/forums/d1...s-mysql-5-7-a/

tintinux avait proposé ceci:

https://sourceforge.net/p/gestinux/c...ySqlDriver.pas

Qui évite de fouiller les répertoires pour créer un lien symbolique. Fonctionne toujours très bien avec la 1.8 svn révision 55559 et linux mint 18.2

[e-ric]

Salut

Ok pour ta distribution mais avec une autre que se passe-t-il ? Cela soulève deux problèmes, en effet :

- si sur une autre distribution, le nom de bibliothèque n'est pas le même (binaire+liens symboliques), tu reviens au point de départ, il te faudra alors quand même définir un lien symbolique avec un nom identique à celui de ton source.

- en modifiant un source que tu ne contrôles pas, tu prends aussi un risque sur ses prochaines versions.

C'est pour cela que je pense que ma solution reste la plus souple même si elle n'est pas parfaite. Le problème de base est l'absence de norme sur les nom de liens symbolique (chaque distribution fait ce qui lui plaît), ce qui en atténue leur intérêt pratique (redirection indépendante de la version).

Cdlt

[mm_71]

si sur une autre distribution, le nom de bibliothèque n'est pas le même (binaire+liens symboliques), tu reviens au point de départ, il te faudra alors quand même définir un lien symbolique avec un nom identique à celui de ton source.

Ça se discute mais si le patch est bien fait il en tient compte, et pour des packages aussi génériques que MySql il me semble que c'est identique au moins pour les distributions à base Debian et Redhat.

en modifiant un source que tu ne contrôles pas, tu prends aussi un risque sur ses prochaines versions.

Là non, si la modif ne fonctionne plus après un upgrade on efface tout et on reprend le fichier original qu'on aurait eu tort de jeter.
Ceci dit il est des circonstances ou le symlink est indispensable et chacun peut avoir ses préférences, tant que quelque chose fonctionne j'en suis satisfait, quand ça ne fonctionne plus je cherche autre chose.