[1.8RC3] Installation de Zeos

Version imprimable

21/07/2017, 15h23
e-ric

[1.8RC3] Installation de Zeos

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:

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
21/07/2017, 18h59
Jipété

Salut,

Citation:

Envoyé par e-ric

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:

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é :plusser:

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, :mouarf:
(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.
21/07/2017, 19h32
e-ric

Citation:

Envoyé par Jipété

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, :mouarf:

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.

Citation:

Envoyé par Jipété

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
23/07/2017, 06h39
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
24/07/2017, 10h42
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
25/07/2017, 10h48
mm_71

Citation:

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.

Citation:

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.
25/07/2017, 11h10
e-ric

Salut

Citation:

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

Dans notre cas, le patch ne fait que corriger pour une distribution données (les noms sont uniques dans le source), sauf à changer la manière dont les bibliothèques sont liées. J'ai eu le problème avec la bibliothèque de SQLite dans la Debian Jessie, ce problème est sans doute inexistant pour une autre distribution (celle du développeur, peut-être Ubuntu) en faisant l'hypothèse que le code a été testé.

Citation:

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.

Selon mon expérience, je n'opterais pas pour une telle approche. J'ai été confronté à des paquets de composants à l'origine identiques mais ayant évolué individuellement qu'il a fallu par la suite fusionner à nouveau, une vraie galère ! avec une valeur ajoutée nulle au final, c'est pour cela que je suis assez méfiant à propos de ta solution. Je pense donc qu'il vaut mieux conserver le code source original (quitte à créer de nouvelles classes dérivées spécifiques).

Cdlt
25/07/2017, 11h48
mm_71

Citation:

Selon mon expérience, je n'opterais pas pour une telle approche. J'ai été confronté à des paquets de composants à l'origine identiques mais ayant évolué individuellement qu'il a fallu par la suite fusionner à nouveau, une vraie galère ! avec une valeur ajoutée nulle au final, c'est pour cela que je suis assez méfiant à propos de ta solution. Je pense donc qu'il vaut mieux conserver le code source original (quitte à créer de nouvelles classes dérivées spécifiques).

Pour des cas aussi complexes c'est exact, par chance je n'ai pas été confronté à ce genre d'avanie. Créer de nouvelles classes dépasse mes compétences et dans ce cas je craque et je passe à autre chose ou j’attends qu'un expert trouve une solution.
26/07/2017, 09h53
tintinux

Bonjour

Juste pour préciser que ce que j'ai proposé avec Zeos et pour MySQL permet les deux solutions : un nom générique de dll indépendant de la version reste disponible, et on peut aussi créer le lien symbolique, si besoin et si possible.

Il faut quand même savoir que pour beaucoup d'utilisateurs finaux c'est très compliqué de créer un lien symbolique dans un terminal, et nombreux sont ceux qui considèrent simplement que "ça ne marche pas" si on exige une telle chose.

Tout dépend donc de la cible, et les deux solutions (lien symbolique ou liste de noms de dll/so/dylib) sont complémentaires.

Il n'en reste pas moins que le code pourrait être plus astucieux, je me suis borné à ajouter les versions connues de MySQL sans modifier le principe un peu lourdingue.
26/07/2017, 10h23
e-ric

Citation:

Envoyé par mm_71

Créer de nouvelles classes dépasse mes compétences et dans ce cas je craque et je passe à autre chose ou j’attends qu'un expert trouve une solution.

Le forum est en partie fait pour cela :).

Citation:

Envoyé par tintinux

Il faut quand même savoir que pour beaucoup d'utilisateurs finaux c'est très compliqué de créer un lien symbolique dans un terminal, et nombreux sont ceux qui considèrent simplement que "ça ne marche pas" si on exige une telle chose.

Cela se comprend mais pourquoi le leur demander ? Pas d'interventions à distance possible ?

@tintinux: je constate que tu as apporté pas mal de modifications, notamment la prise en charge de MacOS/Darwin (j'ai comparé ton source à celui de la version 7.1.4 stable). Tu ne l'as pas proposé à l'équipe Zeos ?

Cdlt
26/07/2017, 11h19
tintinux

Citation:

Envoyé par e-ric

Pas d'interventions à distance possible ?

Non, pas dans certains cas comme pour un logiciel libre tel que Gestinux.

Citation:

Envoyé par e-ric

Tu ne l'as pas proposé à l'équipe Zeos ?

Si, je l'ai proposé mais apparemment sans prise en compte à ce jour.
Ceux qui le souhaitent peuvent insister !