Utilisation de Firebird embedded sous Linux / Ubuntu 18.04

Version imprimable

26/03/2019, 10h49
devEric69

1 pièce(s) jointe(s)

Utilisation de Firebird embedded sous Linux / Ubuntu 18.04

Bonjour,

Je souhaiterais tester Firebird embedded (mono-utilisateur) pour Lazarus (installé) sous Linux (distro. = Ubuntu 18.04).

❶ ==> j'ai trouvé ce premier tutoriel: http://wiki.lazarus.freepascal.org/Firebird_embedded.
Quand je lance la commande aptitude install libfbembed2.5 firebird-dev , j'obtiens le message "Impossible de trouver un paquet dont le nom ou la description corresponde à «*libfbembed2.5*»":

Pièce jointe 461269

❷ ==> j'ai également suivi ce second tutoriel: https://help.ubuntu.com/community/Firebird2.5. J'ai lancé les commandes sudo add-apt-repository ppa:mapopa , puis sudo apt-get update , puis apt-cache search firebird2.5-* . Mais juste après sudo add-apt-repository ppa:mapopa , j'ai les messages d'erreurs...:

Err:9 http://ppa.launchpad.net/mapopa/ppa/ubuntu bionic Release
404 Not Found [IP*: 91.189.95.83 80]
Lecture des listes de paquets... Fait
E: Le dépôt http://ppa.launchpad.net/mapopa/ppa/ubuntu bionic Release n'a pas de fichier Release.
N: Les mises à jour depuis un tel dépôt ne peuvent s'effectuer de manière sécurisée, et sont donc désactivées par défaut

... qui expliquent qu'aucune mise à jour de mon cache n'a été faite pour m'informer de la présence de paquet nommés en firebird2.5-* (impossible à trouver pas dans le ppa http://ppa.launchpad.net/mapopa/ppa/ubuntu bionic Release, vu qu'il n'existe pas).

Quelqu'un connaît-il un moyen (il existe un nouveau ppa pour les dépôts 18.04? maintenant, il faut installer de libfbembed3.{blabla}? ...?) pour installer ces 2 paquets, à partir d'un dépôt ubuntu bionic Release? Je souhaiterais éviter d'installer la totalité d'un serveur Firebird (qui installe aussi, semble-t-il, la version embedded), juste pour utiliser ces 2 paquets, dont tous les tutos disent qu'ils sont seuls nécessaires pour une application mono-utilisateur.
Par avance, merci.
26/03/2019, 11h18
alanglet

Bonjour,

Il y a des explications là http://www.ibphoenix.com/files/Embedded_fb3.pdf

André
26/03/2019, 11h37
devEric69

Bonjour André,

Merci pour le lien: je vais regarder.
26/03/2019, 14h53
devEric69

J'ai regardé: c'est une bonne documentation de culture générale orientée installation, une fois l'application Lazarus terminée.

Ce qui m'intéresse est plus en amont et concerne l'inter-opérabilité EDI-Lazarus <--> firebird-embedded:
- les fichiers avec le soft symlink Debian\Ubuntu: /usr/lib/x86_64-linux-gnu/libfbembed.so pointant vers /user/lib/x86_64-linux-gnu/libfbembed.so.bla.x.y (qui n'est pas installé "out of the box" dans Ubuntu 18.04), nécessaire pour le design-time et run-time dans Lazarus.
- comment créer pas à pas un run-time applicatif dans Lazarus (débogable) en utilisant un chargement dynamique des *.so que je souhaite livrer (la doc. http://www.ibphoenix.com/files/Embedded_fb3.pdf y aide), mais il faut aussi connaître le paramétrage de LD_LIBRARY_PATH, etc: c'est très bien détaillé dans http://wiki.lazarus.freepascal.org/Firebird_embedded, et c'est pour ça que je souhaiterais refaire pas à pas ce tutoriel, pourquoi pas actualisé avec Firebird 3 qui apporte des simplifications dans les couches architecturales de ce SGBDR.
26/03/2019, 19h28
Invité

Bonsoir,

Peut être ce lien https://www.firebirdsql.org/pdfmanua...-embedded.html

ou bien http://www.firebirdfaq.org/faq51/

A priori, sous Linux, il faut installer la version "classic server" pour avoir la librairie qui va bien.

Je n'ai pas essayé car, perso, avec la même distri (Ubuntu 18.04 LTS), j'ai installé Firebird 2.5 super server (je n'ai pas encore migré mes bases vers la version 3.0).

Je pense qu'en cherchant sur le site de Firebird (firebirdsql / firebirdfaq) il devrait y avoir toutes les infos.

Cdt

Laurent
27/03/2019, 17h29
devEric69

Bonjour Laurent,

Je n'ai pas le même niveau que toi en Ubuntu-desktop: c'est pour ça que je veux repartir de zéro à partir du tuto.wiki.lazarus sur firebird-embedded, et voir si j'arrive bien à charger les librairies dans le répertoire de build de mon application, au run-time pour le moins.

Oui, si c'est toujours comme sous Interbase, globalement et de mémoire, la version Super crée, et plusieurs instances du serveur (il y a en sus, une petite application qui fait "chien de garde" si un instance "crash" pour la relancer immédiatement), et un plus grand nombre de sockets d'écoute gérant l'établissement des connexions TCP\IP: la version Super n'est à prendre en compte que pour un environnement avec un énorme multiplexage de connexions, lorsque la version Classic est "à genoux", sachant qu'elle consomme donc plus de mémoire).

J'ai pour l'instant:
- désinstallé (apt - remove blabla) les librairies *firebird*3*.so (pour être sûr de n'installer que les paquets strictement nécessaires, comme semble l'indiquer le tuto.).
- installé dans l'ordre mentionné par l'appli. Gdebi (en respectant sa liste informative "Paquets à installer préalablement à ce paquet courant: .../..."; je suis allé rechercher les paquets depuis https://www.ubuntuupadates.org/package_metas plutôt que d'installer tout le serveur à partir du site de Firebird, donc; j'ai pris tous les paquets avec le même n° de build, dans la distribution Ubuntu \ Xenial, puisque la version Firebird 2.5 avait un dépôt dans Xenial): firebird2.5-common-doc, firebird2.5-common, libfbclient2, firebird2.5-server-common, libicu55 {base}, libfbembed2.5 et firebird-dev.

Voilà tout pour l'instant...
29/03/2019, 15h00
devEric69

1 pièce(s) jointe(s)
Bon, concernant mes avancées... Pour information, j'utilise l'excellentissime outil midnight commander qui encapsule à peu près toutes les commandes du Bash Linux dont j'ai besoin, et me fait gagner du temps: c'est l'équivalent Linux de Norton Utilities ou PC Tools, une suite d'outils système qui étaient un must pour gérer les applications tournant sous MS DOS.
- j'ai désinstallé tous les paquets Firebird 2.5, du dernier installé au premier installé (

Code:

apt-get remove blabla

): en effet, je n'ai pas réussi à lancer les *.SOs à partir de la sempiternelle base employee.fdb récupérée par ailleurs. Ceci dit (je suis novice sous Ubuntu-desktop), ça m'a permis de savoir créer ou overloader la variable d'environnement LD_LIBRARY_PATH (avec la cmd export) avec des chemins qui pointent vers les librairies embedded à livrer. Bon, le truc, c'est que c'est appelé une variable d'environnement comme sous Windows... sauf qu'elle n'est conservée que le temps de la session :? ➔ la solution consiste à écrire la cmd pour ajouter le chemin vers les *.SOs dans le fichier ~/.bashrc . Comme ça, elle reste de reboot en reboot du poste :) .
- j'ai installé (je préfère dans un premier temps faire confiance aux packageurs Ubuntu, plutôt que de partir dans mes propres copier-coller à partir d'un *.tar.gz téléchargé depuis le site https://firebirdsql.org) Firebird 3.0.x à partir de cette doc.: https://help.ubuntu.com/community/Firebird3.0. Tout marche en console via la cmd:

Code:

isql-fb

Il y a juste une astuce qui consiste à lancer les cmd dans le terminal comme indiqué dans /usr/share/doc/firebird-dev/examples/README.Debian pour créer employee.fdb.
- j'ai installé FlameRobin en téléchargent leur dernier *.deb et en suivant leurs prescriptions pour l'install (que je recopie ci-dessous)...:
Code:

1 2 3 4 cd Downloads tar -xJvf ~/Downloads/flamerobin-0.9.3-ff8df8e-x86_64.tar.xz sudo mv opt/flamerobin /opt /opt/flamerobin/bin/flamerobin
... et créé un lanceur avec la cmd

Code:

gnome-terminal -e "bash -c 'sudo -i //opt/flamerobin/bin/flamerobin'"

pour l'avoir dans le dock-quai Ubuntu (j'utilise le bureau Nemo, que je trouve plus sympa. que Nautilus) ➔ FlameRobin se lance et j'ai pu me connecter à employee.fdb:

Pièce jointe 462256

Pour cela, il faut préalablement que le serveur Firebird (dans firebird.conf, personnellement j'ai défini la variable ServerMode = Classic pour permettre et donc éventuellement paramétrer sur les BDD une ou des TCnx en "shared", autocommit ou pas ⇦ j'imagine que cette possibilité doit dépendre du choix de la suite de composants utilisée dans Lazarus; néanmoins, la doc. d'embedded dit que le Provider de protocole de connexions nommé engine12, qui est le plus spé. à l'embedded se "ficherait" de ce paramétrage) tourne, ce qui est vérifiable avec la cmd:

Code:

top -b -n1 | grep [f]irebird

C'est tout pour l'instant.
30/03/2019, 14h33
BeanzMaster

Bonjour Eric très intéressant

Serais-tu partant pour faire un tuto détaillé sur la procedure d'installation ? Est-ce différent (plus simple) sous Windows ?

A+

Jérôme

9 pièce(s) jointe(s)

Citation:

Envoyé par BeanzMaster

Bonjour Eric très intéressant
Serais-tu partant pour faire un tuto détaillé sur la procédure d'installation ?

Bonjour Jérôme.
Je ne ferai pas de tuto. (pas de temps disponible). Par contre, je vais tenter d'aller jusqu'au bout de ce fil en étant aussi didactique que possible.

Citation:

Envoyé par BeanzMaster

Est-ce différent (plus simple) sous Windows ?

Tout d'abord, cela dépend beaucoup des outils avec lesquels on travaille sous Ubuntu.

▪ Pour être aussi confortable que possible, j'ai installé sous Ubuntu 18.04 le gestionnaire de fichiers de "Cinnamon" appelé "Nemo" (je n'utilise donc plus "Nautilus") pour plusieurs raisons:
- on peut naviguer dans l'arborescence certes, mais on peut surtout copier le chemin où l'on est depuis l'en-tête (comme sous l'explorateur de fichiers de Windows)! ==> C'est pratique pour les coller comme paramètres dans les lignes de commandes, plutôt que de taper chaque chemin manuellement.
- on peut ouvrir les répertoires comme root: c'est pratique avec Lazarus, vu que Lazarus et FPC (qui est installé dans mon /home) mettent des droits root:root sur tous leurs fichiers d'installation et parfois sur leur compilation. On peut donc naviguer visuellement dans une arborescence de fichiers root:root, éditer\copier\déplacer ces fichiers comme on veut. En plus, par sécurité, j'ai aussi installé BackInTime pour prendre des clichés de mon poste (façon point de restauration Windows) juste avant l'installation de Lazarus + FCP avec FCPupDeluxe (déjà plusieurs réinstallations à mon actif).

Pièce jointe 463814
Pièce jointe 463822
Pièce jointe 463818
Pièce jointe 463819

▪ J'ai aussi mentionné que j'avais installé "Midnight Commander". Là, ça me fait gagner du temps pour voir\changer des droits, faire des recherches, avec cette interface semi-graphique très utilisée par les développeurs de sites web (qui n'ont pas de bureau visuel, eux).

Pièce jointe 463831

==> Pour en revenir à mes tests en pointillés, je me suis fait une petite base avec FlameRobin (sous /var/lib/firebird/3.0/data/): 3 tables, avec 1 table maître (et 2 tables détails qui ont une "foreign key" pointant dessus). J'ai fait une petite appli., avec un "Form" principale qui ouvre la table maître avec les composants SQLdb (la copie d'écran ci-dessous est effectuée quand je lance l'appli. depuis L'EDI Lazarus: tout fonctionne):

Pièce jointe 463826

J'ai posé dans mon répertoire de compilation (projet nommé project1) les fichiers qui forment l’arborescence suivante:
/home/.../project1
                    |-- ma base *.fb
                    |-- project1 (l'exécutable)
                    |-- firebird.conf
                    |-- firebird.msg
                    |-- @libfbclient.so (raccourci "soft" pointant sur @libfbclient.so.2)
                    |-- @libfbclient.so.2 (raccourci "soft" pointant sur libfbclient.so.3.0.3)
                    |-- libfbclient.so.3.0.3 (la véritable librairie)
                    |
                    └--/intl
                    |     |-- fbintl.conf
                    |
                    └--/plugins
                    |     |-- libEngine12.so
                    |
Alors, je vais expliquer ce que j'ai quand je lance l'eXécutable "project1" en double cliquant dessus. Mais avant, voici mes "pré-requis":
- je suis sûr que ni le service fbguard, ni le service Firebird ne tournent avec la cmd...:

Code:

/etc/init.d/firebird3.0 stop

...puisque top -b -n1 | grep [f]irebird ne me renvoie aucune ligne.
- dans mon fichier ~/.bashrc, j'ai rajouté à la fin:
Code:

1 2 3 # ajout: var. envir. pour Firebird embedded export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/...[SNIP].../rep_project_1:/home/...[SNIP].../rep_project_1/plugins export FIREBIRD=/home/...[SNIP].../rep_project_1
et j'ai vérifié que de reboot en reboot, que la cmd...

Code:

printenv

... me renvoie bien mes chemins. Bon, ci-dessous, ce sont mes vrais chemins (en lieu et place de "/home/...[SNIP].../rep_project_1") pointant sur le rép. qui contient l'eXécutable "project1" :mouarf:.

Pièce jointe 463834

Alors, le but est maintenant de savoir à quel point l'appli. "project1" est embarquée (embedded). Par ça, quand je lance la cmd...

Code:

pidof /home/guepard/SauveWinE_etc/a_projetsLaz/dir_des_divers_boutons_test_all_projets/project1

qui me renvoie, mettons 3093, et que je lance derrière la cmd...

Code:

lsof -p 3093|grep mem

... pour savoir quelles librairies sont chargées\nécessaires par "project1" lancé par double-clic (Lazarus étant fermé), j'ai un résultat mitigé:
❶ ce qui me va, c'est que la *.so libfbclient.so.3.0.3 est bien chargée depuis le rép. où est créée mon appli.:

Pièce jointe 463835

❷ ce qui me va pas, c'est que libtrace.so et libengine12.so sont chargées depuis /usr/.../..., et non pas depuis le rép. où est créé mon appli.

Pièce jointe 463839

☞ Du coup, j'ai revérifié mon /home/guepard/SauveWinE_etc/a_projetsLaz/dir_des_divers_boutons_test_all_projets/firebird.conf.
J'ai fait les modifications suivantes dedans:
- RootDirectory=/home/guepard/SauveWinE_etc/a_projetsLaz/dir_des_divers_boutons_test_all_projets
- DatabaseAccess = Full
- ExternalFileAccess = Full
- UdfAccess = Full
- ServerMode = Classic
==> Ça n'a rien changé.

☞ Avec MC, j'ai renommé /usr/lib/x86_64-linux-gnu/firebird/3.0/.../... en /usr/lib/x86_64-linux-gnu/firebird/6.0/.../..., en pensant le forcer à utiliser les *.so posées dans le rép. où est l'appli. project1.
==> L'appli. refuse d'ouvrir la cnx avec une Exception, que je pose d'ailleurs ces *.so, et dans le rép.-même de l'appli., et dans le sous-rép. .../project_1/plugins.

Voilà. J'ai une appli. semi-embarquée :lol: ( pas terrible pour créer un paquet d'installation: poser les fichiers dans les différents chemins n'est pas compliqué; par contre aller mettre des droits 777 sur tout ce qui est chargé dont des rép. /usr/.../..., c'est "pas glop" :-\. J'aimerais que tout soit chargé depuis mon rép. /home/.../project_1 ).

Je suis preneur de toute idée...

04/04/2019, 23h43
BeanzMaster

Citation:

Envoyé par devEric69

Bonjour Jérôme.
Je ne ferai pas de tuto. (pas de temps disponible). Par contre, je vais tenter d'aller jusqu'au bout de ce fil en étant aussi didactique que possible.

Bonsoir Eric, je comprend, j'ai moi même que très peu de temps libre en ce moment.
Merci d'avance pour tes explications, je rédigerai un tuto dès que j'en aurais l'occasion d'ici cet été et je testerai en parallèle l'installation.

A ce que je peux comprendre de ton problème avec libtrace et libengine12 c'est que ce sont des addons. Les chemins d'accès sont-ils définis dans un autre fichier .conf que firebird.conf ???? fbintl.conf ???? sinon c'est que ta commande :

Citation:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/...[SNIP].../rep_project_1:/home/...[SNIP].../rep_project_1/plugins

ne supporte pas plusieurs chemins.

As tu essayé en mettant les plugins au même niveau que les librairies firebird, dans ton projet ?

A+
05/04/2019, 14h30
devEric69
Bonjour BeanzMaster,

Citation:

Envoyé par BeanzMaster

A ce que je peux comprendre de ton problème avec libtrace et libengine12 c'est que ce sont des addons. Les chemins d'accès sont-ils définis dans un autre fichier .conf que firebird.conf ???? fbintl.conf ????

Effectivement, LibEngine12.so et libtrace.so sont des "plugins" (en gros, ils doivent utiliser la même interface de l'API de Firebird, et exposer leurs services spécieux; ce changement d'architecture permet à n'importe qui de créer des greffons fonctionnels pour le serveur) dans le jargon du serveur Firebird 3.

Citation:

Sinon c'est que ta commande [SNIP] ne supporte pas plusieurs chemins.

Je suis certain que ça ne passe pas sur ton poste pour une raison que ma raison ignore, mais mes chemins suivants...

FBLIB=/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1
FIREBIRD=/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1
LD_LIBRARY_PATH=/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1:/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1/plugins:/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1/lib/intl

... sont bel et bien créés avec ça:
Code:

1 2 3 export FIREBIRD=/home/guepard/SauveWinE_etc/a_projetsLaz/dir_project_num1 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FIREBIRD/plugins:$FIREBIRD/intl
Citation:

As tu essayé en mettant les plugins au même niveau que les librairies firebird, dans ton projet ?

Oui: à la fin, j'ai tout dupliqué, triplé les SOs dans le rép. de mon appli., ainsi qu'également dans des sous-rép. /home/.../project1/plugins et /home/.../project1/intl.

Pour l'instant, je suis toujours à la recherche d'infos. (on m'a d'ailleurs suggéré l'éventualité que les librairies clientes POSIX aient été peut être compilées pour chercher les greffons dans le /plugin d'installation du serveur: il y aurait peut être une suite de chemins en dur, ceux "coutumiers" des POSIX-arch_linux que l'on retrouve dans /etc/ld.so.conf; ensuite, en créant des "soft symlinks" depuis un peu partout pointant vers ces endroits "coutumiers" permettent toujours de s'en sortir; c'est vrai, mais ça ne me plaît pas d'une part: ça n'est pas du tout ce que laisse penser la documentation; et d'autre part, c'est à vérifier). Si j'ai du nouveau, je posterai un retour ici.

A+
05/04/2019, 21h06
alanglet

Bonsoir,

Sur firebirdsql.org un article intitulé "Fast conversion of Firebird 2.5 databases to Firebird 3.0." renvoie vers https://ib-aid.com/en/articles/fast-...to-firebird-3/
La méthode utilisant les versions embedded de FB 2.5 et FB 3 aussi bien sous Linux que sous Windows, il y est expliqué comment les installer.
Vous y trouverez peut-être des renseignements intéressants.
Entre parenthèses concernant l'installation (version complète) sous Linux il est mentionné: It is better to install Firebird 3 from tar.gz, not from the repositories, because tar.gz installs everything into the convenient location /opt/firebird, and also the Firebird version in repositories is usually older than in tar.gz.

André
24/04/2019, 13h54
devEric69

Citation:

Envoyé par alanglet

Bonsoir,
Entre parenthèses concernant l'installation (version complète) sous Linux il est mentionné: It is better to install Firebird 3 from tar.gz, not from the repositories, because tar.gz installs everything into the convenient location /opt/firebird, and also the Firebird version in repositories is usually older than in tar.gz.
André

Effectivement André, pour créer une installation Firebird sous Linux, j'en viens à penser qu'il y a 2 étapes à prendre en compte séparément:
- I au "compile-time", dans Lazarus, si la connexion à une BDD Firebird "crie", le support Lazarus - que je ne blâme absolument pas - indique (ils répondent de même pour SQLite, etc):
1°) d'installer les paquets depuis les dépôts de la version de Linux sous laquelle on est (pour respecter l'idiosyncrasie de chaque installation des distributions Linux). Donc, on se retrouve avec un serveur Firebird et son fbGuard installés. On peut toujours les stopper en lançant:

Code:

/etc/init.d/firebird3.0 stop

2°) si un soft symlink manque quelque part, ils suggèrent ensuite d'installer les paquets dits de "-dev" eg firebird-dev{xxx}: en fait, c'est parce que ces derniers revérifient l'installation et surtout rajoutent les "soft symlinks" manquants.

Au final de ces installations, développer\déboguer depuis Lazarus devient possible, quelque soit sa distro.

- II au "run-time", quand je double-clic sur mon application compilée ( Lazarus fermé ) et que je lance des commandes...

Citation:

readelf

... sur Firebird, libfbclient.so, et libengine12, elles dépendent toutes de la version soname libfbclient.so.2, et toutes de libtommath.so.1, elles-mes dépendantes d'autres *.so (je n'ai pas tout remonté, chaque librairie, loin de là). Mais en regardant les chemins de recherche avec...

Code:

ldconfig -p

... je n'ai que des chemins pointant au même endroit (sous Ubuntu) pour ce qui est des emplacements des librairies Firebird:
libfbclient.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libfbclient.so.2
libtommath.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libtommath.so.1
etc.

Donc, pour résumer mon sentiment, je dirais:
• que l'installation depuis les dépôts est une bonne chose pour pouvoir écrire\déboguer une application avec Firebird depuis Lazarus sur sa distribution (la suite de composants étant neutre; j'ai juste une affinité avec IBX qui de part ses propriétés, montre que cette suite a poussé la compréhension du fonctionnement interne de Firebird plus loin que d'autres).
• Ensuite, il y a l'installation, ou émuler un client. Là je pense effectivement qu'il faudra que je désinstalle, et tout Firebird-serveur, et les variables d'environnement genre FIREBIRD, FBLIB, ..., et les paquets dits de "-dev" (certes, je charge bien libfbclient.so.3.0.3 placée dans mon répertoire; mais toutes les autres dépendances directes et indirectes NEEDED, plutôt nombreuses, sont toutes recherchées dans /usr/lib/x86_64-linux-gnu; et je me demande si LD_LIBRARY_PATH n'est pas shunté au bout d'un moment par le chargement d'une xième dépendance en yième intention) ➔ bref, je devrai repartir d'un poste vièrge côté Firebird.
Ensuite, il faudra que je réinstalle le strict nécessaire en embedded, mais en piochant depuis son *.tar.gz comme tu l'indiques. Ce faisant, j'aurai donc une application avec seulement du code tournant bien mais ne pouvant plus se connecter à une BDD correctement normée 3F ... Il ne me restera plus "qu'à m'énerver" pour trouver la bonne combinaison de fichiers à installer en m'aidant via le truchement de la création d'une installation cliente façon AppImage + son script yaml (mon choix) qui permet et d'indiquer quels et où dézipper des fichiers du *.tar.gz dans le $HOME/.monAppli, et de lancer des scripts d'octrois de droits sur la BDD (chown firebird, sudo chmod 660, etc, voire créer des variables d'environnement), et d'ajouter en dernier recours dans /etc/ld.so.conf les chemins vers /usr/local/lib/my_Appli, $HOME/.monAppli/lib où je mettrai les *.so réfractaires s'il en reste. Et restera encore la possibilité en ultime recours - j'espère ne pas en arriver à cette extrémité - de lier mon application avec des chemins "en dur" aux libraires qu'elle utilise (comme le fait FlameRobin), en la recompilant en précisant au FCP l'emplacement $HOME/.monAppli/lib dans le commutateur -Fl chaîné au linker ld :-\ .

▶ Honnêtement, je pense que le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait aussi pratique que Windows du point de vue des développements desktop, à savoir regarder en priorité d'abord dans le même répertoire que l'application chargée, si la librairie NEEDED ne s'y trouverait pas, par le meilleur des hasards :? .
:pingoin2:

[I]PS: une discussion similaire peut être lue ici (le traducteur https://www.deepl.com est mon ami ;) ):
https://forum.lazarus.freepascal.org...6210#msg316210 .
12/07/2019, 13h54
devEric69

Citation:

Honnêtement, je pense que le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait aussi pratique que Windows du point de vue des développements desktop, à savoir regarder en priorité d'abord dans le même répertoire que l'application chargée, si la librairie NEEDED ne s'y trouverait pas, par le meilleur des hasards.

Bon, le loader ne sera clairement jamais - c'est du moins ce que je crois - mis à jour pour commencer à chercher dans le même rép. que le binaire, comme sous Windows, ce qui simplifiait bien la gestion à minima de la gestion du versioning des librairies spécifiques à l'appli (voire faciliter l'installation et l'utilisation d'autres librairies tiers, comme les *.so d'un SQLite ou d'un Firebird "embedded" sous Linux, en les installant à côté du binaire).

☞ Cependant, pour information, il existe un outil pour injecter \ pitonner dans le binaire, des chemins relatif à lui-même où il doit d'abord aller chercher les *.so sur lesquels il compte, avant que le loader ne prenne ensuite le relai: cet outil s'appelle patchelf ==> Cf. ce complément d'informations sur la gestion du chemin de recherche des *.so sous les distributions Linux... .
20/01/2021, 07h03
jurassic pork

hello,
dans le forum anglais de lazarus, j'ai mis une procédure d'installation du client et de la version embedded de firebird 3 pour Ubuntu 20.04 ici

Il y a comme exemple, mon exemple de base de données de champignons mortels qui se trouve dans la distribution de Lazarus et qui peut utiliser soit une base sqlite3 ou soit une base firebird embedded.
Ami calmant, J.P