SQLite3 auch unter Linux an Programm binden?

[Uwe_9988]

Hallo af0815,

nein, da bin ich anderer Ansicht.

Was auch noch hilft, ist den Benutzer mit der richtigen Information versorgen wenn etwas nicht geht, fehlt oder die falsche Version ist.

"Wenn etwas nicht geht" darf gar nicht erst passieren. Und der Benutzer darf gar nicht mit der Behebung solcher Probleme zu tun bekommen. Nur dann geht es in Richtung Anwenderfreundlichkeit.

Jetzt wird's aber noch mehr OT.

Ich habe bei meiner Arbeit 5 Sekretärinnen und 35 Bauphysiker. Den Bauphysikern könnte ich ja noch einiges zumuten aber bei den Sekretärinnen ist das einfach nicht zu machen. Die würden mir sagen, dass sie was anderes zu tun haben als Softwareprobleme mit mir zu beheben. Und sie hätten sowas von recht.

Gelinkte DLLs an EXE-Files ist einfach ein pragmatischer Ansatz. Dass das nicht die wahre Lehre ist, ist mir schon bewusst. Mich hat ja eigentlich nur interessiert ob es auch unter Linux machbar ist. Die Konsequenzen sind offenbar die gleichen wie unter Windows und mit denen kann ich leben im Zeitalter von 3TB-Platten.


Grüße,
Uwe

[Socke]

"Wenn etwas nicht geht" darf gar nicht erst passieren. Und der Benutzer darf gar nicht mit der Behebung solcher Probleme zu tun bekommen. Nur dann geht es in Richtung Anwenderfreundlichkeit.

Und wer ist dafür verantwortlich, dass dein Programm installiert wird? "Benutzer" sollte zu dem Zeitpunkt, an dem eine Bibliothek nicht installiert wurde, der Systemadministrator und nicht eine Sekretärin oder Bauingenieur sein.
Installationsprogramme wurde extra dafür erfunden, damit alles installiert wird, was man braucht. Wenn man dann hinterher wieder eine Datei manuell löscht, ist man selber schuld.

Das Problem mit dynamischen Bibliotheken ist, dass man nie sicher sein kann, dass die auf dem System vorhandenen zum Programm passen. Das ist bei Windows und Linux ein und dasselbe.

Wie stellst du denn fest, ob die Betriebsystembibliotheken oder die des Widget-Toolkits zu deinem Programm passen? Entweder man benutzt ein Installationsprogramm, bittet den Anwender darum diese vorher zu installieren oder sagt unter Linux der Paketverwaltung, sie möge diese Bibliotheken installieren.

[af0815]

Ich habe bei meiner Arbeit 5 Sekretärinnen und 35 Bauphysiker. Den Bauphysikern könnte ich ja noch einiges zumuten aber bei den Sekretärinnen ist das einfach nicht zu machen. Die würden mir sagen, dass sie was anderes zu tun haben als Softwareprobleme mit mir zu beheben. Und sie hätten sowas von recht.

Und zwar vollkommen. Wie schon Socke schrieb - S&B sollen arbeiten, der Programmierer vernünftig arbeiten. Wir habe bei uns mehrere Dutzend (ca. 200) PCs. Und die Benutzer sind teilweise User, die es schaffen den PC abzudrehen und aufzudrehen ohne größere Probleme zu haben und mit ein paar wenigen tw. speziellen Programmen zu arbeiten.
Das tun die 24 Std, 7 Tage die Woche, 360 Tage im Jahr. Und dort musst du 1stens die Programme tw. schreiben, 2tens verteilen UND 3tens Support leisten. Die rufen Dich aber um 2 in der früh an und sagen - welcher sch$§%& Programmierer hast die Software geschrieben. Fehler machst du in diesem Umfeld nicht oft, zumindest nicht, wenn du auch auf ungestörtes Privatleben stehst.
Da setzt du dich lieber hin und lernst mit den Installern und Standartechniken der Softwaredistribution umzugehen. Denn von Rechner zu Rechner laufen bei jedem kleinen Update ist auch nicht schön. Lieber das Install/Deinstall beherrschen und mit Richtlinen und oder Scipts die Software zuweisen, dann ist es kein großes Problem.

[Uwe_9988]

Wenn man dann hinterher wieder eine Datei manuell löscht, ist man selber schuld.

Kann mit DLL in der Ressource nicht passieren außer man löscht das ganze Programm.

Wie stellst du denn fest, ob die Betriebsystembibliotheken oder die des Widget-Toolkits zu deinem Programm passen? Entweder man benutzt ein Installationsprogramm, bittet den Anwender darum diese vorher zu installieren oder sagt unter Linux der Paketverwaltung, sie möge diese Bibliotheken installieren.

Sicher kann man nicht alles an ein Programm binden, was es zum Laufen benötigt aber das heißt ja nicht, dass man sich das Leben nicht da erleichtern kann, wo es geht, oder? In vielen Fällen kann ich als Entwickler schon abschätzen in welchen Umgebungen ein Programm laufen soll.

Theoretisch habt ihr ja recht aber eben nur theoretisch. Wenn es einem Admin oder einem Benutzer oder mir auch nur einmal einen lästigen Fehler erspart, dann hat es sich doch schon gelohnt. Unter Windows verwende ich das nun schon seit ca. fünf Jahren und wegen einer fehlenden oder falschen MySQL.dll/SQLite.dll gab es nie Probleme. Zuvor ist das doch immer mal passiert.

Unser Büro verwendet CentOS als einzige Linuxdistribution. Programme die ich dafür schreibe, werden garantiert nie unter Ubuntu oder sonstwas laufen müssen. Für mich wäre es einfach nur praktisch, wenn ich jetzt schon entsprechende Bibliotheken an Lazarusprogramme binden könnte und ich würde es sofort benutzen.

Ich finde sowas muss man problembezogen sehen. Wenn sich etwas in der Praxis bewährt hat, dann kann man es auch verwenden, selbst wenn das irgendwelchen IT-Prinzipien widerspricht.

Es spart Zeit und Geld also ist es gut.


Grüße,
Uwe

P.S.: Ich habe nichts dagegen irgendetwas zu installieren, muss ich ja auch ständig machen. Geht ja eigentlich nur darum ob man DDLs/SOs an Programme binden sollte oder nicht. Schadet nicht, würde ich sagen.

[Socke]

Wenn es dir nur um die richtige Bibliotheksversion geht, kannst du unter Linux deine Programme auch an die richtige Version binden, indem du sie einfach in den API-Units mit angibst:

Code: Alles auswählen

function myfunc(param1: longint): longint; cdecl; external 'libmysqlclient.so.15.0.0';

Du hättest natürlich auch 'libmysqlclient.so' oder 'libmysqlclient.so.15' schreiben können, aber so wird die Version sichergestellt, sofern installiert.

Wenn du natürlich das Mitliefern bevorzugst, fällt mir ein:

• Shared Objects als Ressource ins Programm linken
• Bei Programmstart in ein temporäres Verzeichnis extrahieren
• Kopie der Umgebungsvariablen erzeugen; temporäres Verzeichnis in LD_LIBRARY_PATH hinzufügen
• Fork auf dein eigenes Programm mit den neuen Umgebungsvariablen
• hoffentlich funktioniert jetzt alles; ansonsten dynamic late binding mit absoluten Pfaden durchführen
• Bei Programmende: Verzeichnis löschen (solange keine andere Programminstanz gestartet wurde, aber die Bibliotheken noch nicht geladen hat, funktioniert das einwandfrei)

[Uwe_9988]

Hallo Socke,

Wenn du natürlich das Mitliefern bevorzugst, fällt mir ein:
Shared Objects als Ressource ins Programm linken
Bei Programmstart in ein temporäres Verzeichnis extrahieren
Kopie der Umgebungsvariablen erzeugen; temporäres Verzeichnis in LD_LIBRARY_PATH hinzufügen
Fork auf dein eigenes Programm mit den neuen Umgebungsvariablen
hoffentlich funktioniert jetzt alles; ansonsten dynamic late binding mit absoluten Pfaden durchführen
Bei Programmende: Verzeichnis löschen (solange keine andere Programminstanz gestartet wurde, aber die Bibliotheken noch nicht geladen hat, funktioniert das einwandfrei)

War das jetzt ironisch gemeint?

Also "Shared Objects als Ressource ins Programm linken" mache ich doch schon unter Windows. Genau darum geht's doch. Temporäres Verzeichnis brauche ich nicht, passiert alles im Speicher. Das Filesystem ist überhaupt nicht beteiligt außer zum Laden der Ressource, die am Programm hängt. Das ist ja gerade der Witz an der Sache. Wenn man da noch was auspacken oder aufräumen müsste, könnte man sich den ganzen Aufwand sparen.

Grüße,
Uwe

[Socke]

War das jetzt ironisch gemeint?

Also "Shared Objects als Ressource ins Programm linken" mache ich doch schon unter Windows. Genau darum geht's doch. Temporäres Verzeichnis brauche ich nicht, passiert alles im Speicher. Das Filesystem ist überhaupt nicht beteiligt außer zum Laden der Ressource, die am Programm hängt. Das ist ja gerade der Witz an der Sache. Wenn man da noch was auspacken oder aufräumen müsste, könnte man sich den ganzen Aufwand sparen.

Nein, war schon ernst gemeint (vielleicht hätte ich auch eine nummerierte Liste verwenden sollen..). Linkst du zu deinen Bibliotheken direkt in den Ressourcen-Teil deiner Anwendung hinein?
Vielleicht gehts einfacher, wenn du ein Dateisystem im Haputspeicher erstellst und die Dateien dorthin lädst. Hinterher einfach unmounten und sie sind weg.

[Uwe_9988]

Hallo Socke,

also unter Windows funktioniert es mit dem BTMemoryModule von Martin Offenwanger (hänge ich mal dran). Im Wesentlichen sind das Funktionen für GetProcAddress und Loadlibrary, die direkt eine DLL im Speicher ansprechen können. Das habe ich mit meinen Wrappern für MySQL und SQLite verheiratet.

Funktioniert mit Delphi/Lazarus unter Win32. Interessieren würde mich wie hoch der Aufwand ist das ganze für Win64 und Linux anzupassen.

Mit Delphi kann man keine MS-C-Libraries statisch linken weil Borland/MS verschiedene Objectformate verwenden. Es gibt zwar irgendwelche Konverter aber als ich damals danach suchte habe ich keine gute Lösung gefunden.

Zum Thema "DLLs in Resourcen direkt aufrufen" noch folgender Link: load-resource-dll-into-memory

Grüße,
Uwe

[Socke]

Wenn ich das richtig sehe, geht diese Unit schon ziemlich nah an die Betriebssystem-Ebene. Ich weiß nicht inwiefern das unter Linux auch möglich ist, aber im Zweifelsfall hast du ja die Quellen
Für Win64 dürfte der Aufwand nicht all zu groß sein, da sich in der Archtiektur nicht viel getan haben dürfte.

Mit Delphi kann man keine MS-C-Libraries statisch linken weil Borland/MS verschiedene Objectformate verwenden. Es gibt zwar irgendwelche Konverter aber als ich damals danach suchte habe ich keine gute Lösung gefunden.

Wie siehts denn mit FPC und GCC aus? Im Notfall kannst du ja auch noch auf GNU ld zurückgreifen; daher sollten beide Compiler das selbe Object-Format verwenden.

[Uwe_9988]

Hallo Socke,

Wie siehts denn mit FPC und GCC aus? Im Notfall kannst du ja auch noch auf GNU ld zurückgreifen; daher sollten beide Compiler das selbe Object-Format verwenden.

Sollte ja eigentlich funktionieren, wenn man C-Quellen von MySQL oder SQLite oder was auch immer verwendet, die durch den GCC jagt und mit dem FPC-Linker an die Lazarusanwendung linkt. Zumindest theoretisch. Werde mir mal ein paar Makefiles und die Linkeroptionen anschauen.

Das ist unter Windows halt ein weiterer Vorteil von dem DLL-Resource-Gelinke. Man kann einfach die Binaries von den entsprechenden Downloadseiten verwenden, dazulinken und fertig.

Aber bei Linux (und oft auch bei Win64) muss man für die Binaries ja eh meistens den Compiler auspacken. Na mal sehen...


Grüße,
Uwe

[af0815]

Werde mir mal ein paar Makefiles und die Linkeroptionen anschauen.

Stichwort: Buildfaq von Marco

[Ralf]

Hallo zusammen,

ich passe gerade einige SQLite3-Units an (Wrapper und ein paar nützliche Klassen), die ich unter Delphi verwendet habe und die ich um Funktionen erweitert habe, die ein linken der sqlite3.dll als Resource ermöglichen. Zur Laufzeit werden die Funktionen der dll dann direkt im Speicher ausgeführt.

Man kann also die Funktionen der dll verwenden ohne die dll im Programmverzeichnis entpacken oder überhaupt mitgeben zu müssen. Außerdem muss man sich nicht um dll-Versionen kümmern, weil automatisch die richtige dll verwendet wird.

Unter Windows funktioniert das schon für Win32 sowohl mit Delphi als auch mit Lazarus.

Meine Frage ist jetzt, ob es sinnvoll/möglich ist das ganze auch an Linux anzupassen oder ob sich diese Problematik unter Linux gar nicht so stellt. (Dass es sqlite3 schon für Lazarus gibt, ist mir bewusst. Es geht eher um den Gedanken eine dynamische Library statisch an ein Programm zu binden. )


Grüße,
Uwe

Hallo Uwe,

ich bin mir bewusst, dass der Thread schon uralt ist und du vielleicht schon nicht mehr mitliest, jedoch ist die (deine) Frage nach wie vor aktuell (zumindest für mich ).
Ich sehe diesen Aspekt genauso wie Du (alle Dateien mitliefern wollen) und interessiere mich daher auch für die Frage, ob ich unter Linux die Lib (genauer sqlite3.so oder libsqlite3.so) irgendwie in dem Programmverzeichnis (das finale Anwenderverzeichnis) kopieren kann. Ich möchte garnicht so weit gehen und die unbedingt zusammenlinken wollen (was natürlich seinen Charme hätte).

Das funktioniert durch einfaches Kopieren jedenfalls schon mal bei mir nicht so einfach, wie zu erwarten war.
Lazarus (bzw. Linux) scheint nicht automatisch im aktuellen Programmpfad die Library zu suchen....

Habe aus /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 (der symbolische Link @libsqlite3.so zeigt darauf) in mein finales Programmverzeichnis kopiert. Auf dem Ziel-PC ist keine SQLite3 Version installiert, es ist dort auch keine Lib vorhanden (gut zum Testen).

Wenn ich das Programm starte und die DB öffnen will erscheint:

Code: Alles auswählen

 
Can not load SQLite client library "libsqlite3.so". Check your installation.
 
Press OK to ignore and risk data corruption.
Press Abort to kill the program.
 

Die Dateirechte der sqlite3.so sind: 775, Owner ist der Benutzer, nicht Root.

In meinem kleinen Testprogrämmchen habe ich auch nirgends den Libpfad angeben müssen, das machen scheinbar die Komponenten (SQLite3Connection, SQLTransaction, SQLQuery) automatisch und so findet Lazarus auf meinen Entwickler-PC (hier natürlich SQLite3 installiert) die Library.

Ich verbinde im Testprogramm lediglich die Komponenten untereinander und gebe die DB unter SQLite3Connection.Database an und öffne diese mit SQLite3Connection.open.
Fertig, löppt sofort auf dem Entwickler-PC.

Jetzt wäre prima, wenn ich auf dem Ziel-PC (ebenfalls Linux mit Kubuntu 18.04, genauer der Virtualbox-Host, entwickelt wird in einem Gast mit selben OS) das Programm starten könnte, ohne dass dort explizit SQLite3 installieren muss.
Ich bin mir bewusst, dass dieses Vorgehen nicht der Philosophie vieler Entwickler entspricht, doch für mich ist es übersichtlicher und einfacher zu handeln und es gibt so keine Konfikte mit anderen Programmen etc.
Viele lieb gewonnene Tools sind mir da Vorbild, wo ich lediglich das Programmverzeichnis irgendwohin kopieren kann und es sofort funktioniert... ohne irgendwelche Installation.

Kann mir wer auf die Sprünge helfen und Tipps geben?

Viele Grüße,
Ralf

[af0815]

Dafür gibt es eine Lösung, statisch ins Programm linken. Oder ein Installationspaket selbst erzeugen, wo die Abhängigkeit angegeben ist. Oder der IT-Verwaltung einen Katalog geben, welche Bibliotheken am Rechner zu sein haben.