Discussion :

[Invité]

Bonjour,

je peste des fois contre Linux et aujourd'hui c'est le cas. J'ai un programme développé avec Lazarus qui fonctionne en Win 32 et 64 et fonctionnait en Linux 32 et 64. Il travaille avec une base de données MySQL hébergée mutualisée ce qui signifie que je ne peux pas modifier son my.cnf.

A l'époque où j'ai fait ce programme, la version de la base de données MySQL était 5.0 (pour être précis 5.0.96). En Nux cela correspond à libmysqlclient.so.15. "Chez" MySQL, le format d'identification de connexion aux bases a été modifié dans les versions suivantes [old_password]... Il faudrait modifier le my.cnf pour qu'une version actuelle d'un driver de MySQL me permette de me connecter. C'est impossible... Et l'autre solution envisagée, installer sur une Ubuntu 14.04 un obsolète libmysqlclient.so.15 et toutes ses dépendances tout aussi obsolètes qui vont entrer en concurrence avec les actuelles librairies clientes fournies dans les dépôts, est une véritable gageure.

Donc j'ai transféré hier ma base sur mon serveur MariaDB 5.5 qui lui aussi est hébergé (et n'est pas mutualisé... J'ai "compris" depuis). Mais par curiosité, je me demandais s'il n'y avait pas une autre approche possible ?

Evidemment pour les versions Windows le refus d'identification est le même lors d'une tentative de connexion à la base avec un libmysql.dll de version 5.6. Mais, comme Win 32 (et 64) n'ont guère changé depuis des années, il suffit de télécharger une vieille libmysql.dll version 5.0.96 pour contourner le problème.

Merci.

[yamer]

Evidemment pour les versions Windows le refus d'identification est le même lors d'une tentative de connexion à la base avec un libmysql.dll de version 5.6. Mais, comme Win 32 (et 64) n'ont guère changé depuis des années, il suffit de télécharger une vieille libmysql.dll version 5.0.96 pour contourner le problème.

Sous Linux aussi tu peux faire ce genre de choses.

1. Tu places ton executable et tes vieilles bibliothèques dans un dossier (genre /opt/monprg par exemple).
2. Tu créés dans /usr/bin un script shell qui initialise la variable d'environement LD_LIBRARY_PATH à /opt/monprg puis lance le programme contenu dans /opt/monprg.
3. Tu lances le script.

exemple de script :

Code :

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

1
2
3
4
5
6
 
#!/bin/bash
PRGNAME=monprg
DIRNAME=/opt/monprg 
export LD_LIBRARY_PATH=$DIRNAME 
$DIRNAME/$PRGNAME

[Invité]

Bonjour,

dans ce cas précis, je ne crois pas. Feu libmysqlclient.so.15 a des dépendances et sous-dépendances qui ne sont compatibles avec la version de l'OS utilisé, ni installables. Donc, si l'idée est de les faire cohabiter ou de remplacer l'une par l'autre, à ma connaissance, ce n'est pas jouable. Ce qui, à mon avis, ne permet pas d'utiliser votre solution.

Autre solution à rejeter, créer un lien... Ce serait totalement inutile car la libmysqlclient.so.18 n'est pas compatible avec ma base pour les raisons que j'ai expliquées.

Par contre en général, si la librairie n'est pas trop ancienne, on peut bricoler comme par exemple ici avec Qt 5.3... (je n'en suis pas l'auteur mais cela résume bien le problème rencontré) :

Re: QSqlDatabase: QMYSQL driver not loaded but available
I have had the similar problem on Kubuntu 14.04 64 bit with the latest 5.3.1 Qt relase downloaded from the qt-project and installed to the /opt.
The Ubuntu 14.04 ships with libmysqlclient 18 while the Qt 5.3.1 is built with 16. So the creating of a symlink like above did not solved my issue.
Finally I have downloaded the libmysqlclient 16 from here:
[...] And extraceted the library files to my /usr/lib/x86_64-linux-gnu folder.

[http://www.qtcentre.org/threads/55365-QSqlDatabase-QMYSQL-driver-not-loaded-but-available]

Dans ce problème que j'ai donc rencontré, je n'ai pas voulu installer la version 16 puisque nativement sur les postes Ubuntu 14, c'est la version 18 qui est installée... Donc la solution proposée par l'interlocuteur n'est pas aisément portable sur les postes Clients. Donc recompilation de l'environnement de développement incluant la version 18 (incomplètement d'ailleurs). C'est pour cela que je trouve Lazarus très sympa. Mais là, le problème me semble incontournable. Cependant les approches en Linux sont nombreuses... On ne sait jamais.

Merci pour votre aide.

[yamer]

A ma connaissance la procédure que je t'ai indiquée doit fonctionner. Il suffit de placer dans le dossier de ton programme la bibliothèque mysql et éventuellement les bibliothèques dont elle dépend (si les bibliothèques installées sur le système ne sont pas compatibles). Ces bibliohèques ne seront utilisées que par le programme lancé par le script. Elles ne remplacent pas les libs ubuntu pour les autres programmes. Tu peux récupérer les vieilles bibliothèques dans les anciennes version ubuntu. Pour déployer sur les postes clients c'est simple tu copies le dossier qui contient le programmes et les bibliothèques ainsi que le script.

Si tu veux comprendre comment ça marche renseignes toi sur la variable d'environnement LD_LIBRARY_PATH. Tu peux aussi te renseigner dans la section linux du forum il y a peut être d'autres méthodes.

[Jipété]

Bonsoir,

Donc j'ai transféré hier ma base sur mon serveur MariaDB 5.5 qui lui aussi est hébergé (et n'est pas mutualisé... J'ai "compris" depuis). Mais par curiosité, je me demandais s'il n'y avait pas une autre approche possible ?

Moi, les vieux softs auxquels je tiens et qui ne pourront pas / plus évoluer, je les fige dans des machines virtuelles dédiées, par exemple ma messagerie Outloook Express tourne dans une MV XP SP2 qui ne sert qu'à ça et, ma foi, ça le fait bien.

[Invité]

Bonjour,

@Yamer : je tenterai votre solution sur un autre appareil. Mais j'ai toujours un doute.
Je regarde les packages des 2 versions (ou équivalentes), un accès mysql lucid et un trusty:

• http://packages.ubuntu.com/lucid/mysql-client-5.1
• http://packages.ubuntu.com/trusty/mariadb-client-5.5

Tous les 2 utilisent comme dépendances libc6 (cf les pages internet).
La "vieille" libc6 (>= 2.4) pour l'un et la nouvelle libc6 (>= 2.17) pour l'autre. Evidemment je peux placer l'ancienne libc6 (>= 2.4) dans un répertoire dédié à l'ancienne. Mais libc6... dépend de libgcc1, de debconf qui dépendent de...

A un moment, il va bien falloir qu'il y ait un socle commun à l'ancienne et la nouvelle et forcément, ce seront des dépendances de Ubuntu 14... qui ne seront pas évidemment compatibles avec les vieilles.

Donc j'essayerai mais je reste sceptique.

@Jipété : original en effet... Mais je me vois mal installer une VM sur chacun de mes postes clients.

[Invité]

Bonjour,

Pour clore cette discussion, méthode testée pendant les vacances scolaires : Echec complet. Et pourtant je suis allé aussi loin que possible pour satisfaire les dépendances récupérées sur un poste secondaire installé avec une vieille Ubuntu, au point qu'il m'a fallu ré-installer mon Ubuntu 14 pour la "re-stabiliser". Donc la bonne méthode était bien de mettre à jour (migrer dans mon cas) le serveur mySQL.

Tous mes voeux.