Shared libraries in Linux in welchen Path

[Acia6850]

Hallo ich habe eine Consolen Anwendung in Windows 10 64Bit geschrieben welche verschiedene C-Libs benötigt.

In Windows werden die Dlls im Exe verzeichniss hinterlegt.

Die C-Libs und die Lazarus Exe habe ich nach Linux portiert (Raspi OS 64 Bit, Linux Debian 64 Bit und Linux Mit 64 Bit)
sie laufen auf allen Systemen.

Nun die Frage : in welches Verzeichnis in Linux kopiert man die Shared Libraries ohne das man den Library-Path in Linux setzen muss.

[Mathias]

Nun die Frage : in welches Verzeichnis in Linux kopiert man die Shared Libraries ohne das man den Library-Path in Linux setzen muss.

Wen du die *.so und *.so.x.x meinst, am besten in /usr/local/lib

Um welche C-Libs handelt es sich ?
Selbst gebaute oder um fertige Standard-Libs ?

[juelin]

versuch es mal in /usr/lib
Gruß
Jürgen

[photor]

versuch es mal in /usr/lib

Moin,

also eigentlich gehören in /usr/lib nur System-eigene Libs (also solche, die vom Package-System verwaltet werden). Deshalb würde ich die auch eher nach /usr/local/lib packen.

Ciao,
Photor

[Mathias]

also eigentlich gehören in /usr/lib nur System-eigene Libs (also solche, die vom Package-System verwaltet werden). Deshalb würde ich die auch eher nach /usr/local/lib packen.

Genau so ist es.

Kommerzielle libs kommen in /opt/packetname/lib

[Warf]

Wenn du die Bibliotheken selbst für diese Anwendung gebaut hast, am besten nicht system weit installieren sondern einfach lokal mitliefern und über die LD_LIBRARY_PATH Umgebungsvariable den Suchpfad angeben. Typischerweise baut man sich eine kleine Ordnerstruktur mit program/bin, program/lib program/share, etc. Das kann man dann irgendwo installieren, z.B. im Nutzerordner oder Systemweit in /opt. Und Dann ein start script nutzen die subpfade zu den Umgebungsvariablen hinzufügt bevor es dann das hauptprogramm startet.

Wenn du die Sachen systemweit installieren kannst du das selbe machen und nach /opt verschieben, und dann symlinks in /usr/local erstellen

[Zvoni]

Ich würde mir erstmal die Frage stellen, welche ANDEREN Programme AUSSER deiner Konsolen-Anwendung auf diese lib's zugreifen müssen/sollen/wollen.

Weil wenn die Antwort nämlich KEINE ist, dann würde ich sie direkt im Verzeichnis deiner Anwendung belassen (ggfs. in Unterordner dort, wie auch bereits von Warf erwähnt)

[Acia6850]

Vielen Dank für die Antworten und Beispiele.

Ich habe mir überlegt den Aufruf von ($LD_LIBRARY_PATH) in ein shell script oder in die Lazarus Exe zu in­te­g­rie­ren.

Die shared Library kommt in das gleiche Verzeichnis wie die Lazarus Anwendung.

Die Anwendung prüft zuerst das vorhandensein der Library-Datei.
Bei Erfolg wird der ($LD_LIBRARY_PATH) hinzugefügt und dann die Library-Datei dynamisch geladen.

So wäre der Aufruf für den Anwender und die Installation der Applikation am einfachsten.

Grüße Acia6850

[Zvoni]

Die Anwendung prüft zuerst das vorhandensein der Library-Datei.
Bei Erfolg wird der ($LD_LIBRARY_PATH) hinzugefügt und dann die Library-Datei dynamisch geladen.

Wozu das ganze LD_LIBRARY_PATH-Gehampel??
https://www.freepascal.org/docs-html/3. ... brary.html

No assumptions should be made about the location of the loaded library if a relative pathname is specified. The behaviour is dependent on the platform. Therefore it is best to specify an absolute pathname if possible.

Da du sowieso das vorhandensein der lib prüfst (FileExists?), benutz doch einfach den absoluten Pfad, und gut ist.

[photor]

Die Anwendung prüft zuerst das vorhandensein der Library-Datei.
Bei Erfolg wird der ($LD_LIBRARY_PATH) hinzugefügt und dann die Library-Datei dynamisch geladen.

Wozu das ganze LD_LIBRARY_PATH-Gehampel??
https://www.freepascal.org/docs-html/3. ... brary.html

No assumptions should be made about the location of the loaded library if a relative pathname is specified. The behaviour is dependent on the platform. Therefore it is best to specify an absolute pathname if possible.

Da du sowieso das vorhandensein der lib prüfst (FileExists?), benutz doch einfach den absoluten Pfad, und gut ist.

Eine kurze Anmerkung hierzu: ich hatte mich gewundert, dass ich auf meinem ArchLinux keinen LD_LIBRARY_PATH (z.B. mittels env | grep LIB gefunden habe.

Wenn ich meine (noch kurze) Recherche richtig verstehe, wird in den heutigen Linuxen diese Environment-Variable so direkt nicht mehr gesetzt. Es gibt wohl mittlerweile andere Mechanismen.

Also, bevor hier zu viele Lösungen um genau diese drehen. Ich gebe aber zu, dass ich auch überrascht bin - und wohl mal mein Linux-Wissen aktualisieren müsste.

Ciao,
Photor

[Zvoni]

Ich verstehe immer noch nicht, warum auf dem LD_LIBRARY_PATH rumgeritten wird.
LD_LIBRARY_PATH wird bekanntlich gebraucht, um systemweit libs zu finden bzw. MEHREREN Programmen die chance zu geben, ein und diesselbe lib zu nutzen, welches wiederum impliziert, dass diese lib an einem "zentralen" Ort liegt
OP hat doch selbst schon bestätigt, dass seine lib im gleichen Ordner wie seine executable liegt, und er sowieso erst prüft, ob die so überhaupt vorhanden ist.

LD_LIBRARY_PATH ist vollkommen überflüssig hier, vorausgesetzt, seine Konsolenanwendung ist das EINZIGE Programm was diese lib braucht

[photor]

LD_LIBRARY_PATH ist vollkommen überflüssig hier, vorausgesetzt, seine Konsolenanwendung ist das EINZIGE Programm was diese lib braucht

Ich gebe dir vollkommen Recht: ich würde eine Lib immer da unterbringen, wo sie gebraucht wird:

• im Programmverzeichnis, wenn die nur für dieses eine Programm gebraucht wird
• im User-Verzeichnis (z.B. ~USER/lib/) wenn nur ein User diese Lib braucht
• systemweit, wenn eine Lib im ganzen System gebraucht wird (z.B. /uss/local/lib - wenn nicht vom Packege-Manager verwaltet; sonst /usr/lib wenn doch - aber dann ist die Diskussion überflüssig)

So ist zumindest mein Verständnis. Da ich nicht wirklich weiß, was der Frager will, ...

Ciao,
Photor

[Warf]

OP hat doch selbst schon bestätigt, dass seine lib im gleichen Ordner wie seine executable liegt, und er sowieso erst prüft, ob die so überhaupt vorhanden ist.

LD_LIBRARY_PATH ist vollkommen überflüssig hier, vorausgesetzt, seine Konsolenanwendung ist das EINZIGE Programm was diese lib braucht

Wir reden hier aber nicht von Windows sondern von Linux. Der executable pfad ist in Linux im gegensatz zu Windows nicht Teil des Suchpfades: https://man7.org/linux/man-pages/man8/ld.so.8.html

Code: Alles auswählen

       (1)  Using the directories specified in the DT_RPATH dynamic
            section attribute of the binary if present and DT_RUNPATH
            attribute does not exist.

       (2)  Using the environment variable LD_LIBRARY_PATH, unless the
            executable is being run in secure-execution mode (see
            below), in which case this variable is ignored.

       (3)  Using the directories specified in the DT_RUNPATH dynamic
            section attribute of the binary if present.  Such
            directories are searched only to find those objects required
            by DT_NEEDED (direct dependencies) entries and do not apply
            to those objects' children, which must themselves have their
            own DT_RUNPATH entries.  This is unlike DT_RPATH, which is
            applied to searches for all children in the dependency tree.

       (4)  From the cache file /etc/ld.so.cache, which contains a
            compiled list of candidate shared objects previously found
            in the augmented library path.  If, however, the binary was
            linked with the -z nodefaultlib linker option, shared
            objects in the default paths are skipped.  Shared objects
            installed in hardware capability directories (see below) are
            preferred to other shared objects.

       (5)  In the default path /lib, and then /usr/lib.  (On some
            64-bit architectures, the default paths for 64-bit shared
            objects are /lib64, and then /usr/lib64.)  If the binary was
            linked with the -z nodefaultlib linker option, this step is
            skipped.

Das Programmverzeichnis ist nicht enthalten. D.h. wenn man den Suchpfad nicht über LD_LIBRARY_PATH angibt, wird das Program die Bibliothek nicht finden, selbst wenn sie im selben Verzeichnis liegt.

Das ganze macht auch Sinn denn was ist das Verzeichnis in dem die Executable liegt? Unter Linux wird sehr viel mit Symlinks gearbeitet, und wenn man z.B. ArgV[0] checkt, ist da der Pfad des Symlinks drin, nicht der Pfad des Programms (FPC macht ne dynamische Auflösung wenn man ParamStr(0) aufruft). Für das System ist komplett transparent wo das Programm eigentlich liegt.

[Zvoni]

Das Programmverzeichnis ist nicht enthalten. D.h. wenn man den Suchpfad nicht über LD_LIBRARY_PATH angibt, wird das Program die Bibliothek nicht finden, selbst wenn sie im selben Verzeichnis liegt.

Das ganze macht auch Sinn denn was ist das Verzeichnis in dem die Executable liegt? Unter Linux wird sehr viel mit Symlinks gearbeitet, und wenn man z.B. ArgV[0] checkt, ist da der Pfad des Symlinks drin, nicht der Pfad des Programms (FPC macht ne dynamische Auflösung wenn man ParamStr(0) aufruft). Für das System ist komplett transparent wo das Programm eigentlich liegt.

Und du hast leider den wichtigen Teil überlesen

Vielen Dank für die Antworten und Beispiele.

Ich habe mir überlegt den Aufruf von ($LD_LIBRARY_PATH) in ein shell script oder in die Lazarus Exe zu in­te­g­rie­ren.

Die shared Library kommt in das gleiche Verzeichnis wie die Lazarus Anwendung.

Die Anwendung prüft zuerst das vorhandensein der Library-Datei.
Bei Erfolg wird der ($LD_LIBRARY_PATH) hinzugefügt und dann die Library-Datei dynamisch geladen.

So wäre der Aufruf für den Anwender und die Installation der Applikation am einfachsten.

Grüße Acia6850

Er prüft ZUERST, ob seine lib überhaupt vorhanden ist!! Bedeutet: Er hat bereits die File-Location der lib!!
Er braucht nur den absoluten Pfad für LoadLibrary zu nehmen

EDIT: OK, ich glaube, ich muss ein wenig zurückrudern.
LD_LIBRARY_PATH wird NICHT benötigt, wenn OP voll dynamisch die lib laden will (mit "LoadLibrary" und "GetProcAddress")

Wenn OP aber dieses seltsame "halb-dynamisch/halb-statische" Verfahren benutzt

Code: Alles auswählen

Function Foo(SomeArg:cint):cint;cdecl;external 'somelib.so';

Dann kommt LD_LIBRARY_PATH tatsächlich ins Spiel (glaub ich zumindest)

Ich glaube wir haben alle irgendwie aneinander vorbeigeredet....

[Socke]

EDIT: OK, ich glaube, ich muss ein wenig zurückrudern.
LD_LIBRARY_PATH wird NICHT benötigt, wenn OP voll dynmaisch die lib laden will (mit "LoadLibrary" und "GetProcAddress")

Wenn OP aber dieses seltsame "halb-dynamisch/halb-statische" Verfahren benutzt

Code: Alles auswählen

Function Foo(SomeArg:cint):cint;cdecl;external 'somelib.so';

Dann kommt LD_LIBRARY_PATH tatsächlich ins Spiel (glaub ich zumindest)

Ich glaube wir haben alle irgendwie aneinander vorbeigeredet....

Damit ein vollständiges Bild herrscht:

• Beim statischen Linken werden die Bibliotheken durch den Linker direkt in das Executable eingebunden. Ein Nachladen zur Laufzeit ist nicht notwendig - das passiert mit allen im Programm verwendeten Free Pascal Units.
• Beim dynamischen Linken unterscheidet man zwischen early binding und late binding
  • Beim early binding wird dem Compiler/Linker mitgegeben, welche Bibliothek und welche Funktionen daraus genutzt werden. Diese Informationen werden in die Programmdatei geschrieben, sodass der Betriebssytemlinker beim Programmstart (bevor der Code darin ausgeführt wird) die Bibliotheken suchen und nachladen kann. Warf hat das Verfahren gut beschrieben/zitiert. Über den beschriebenen Mechanismus kann man gut kontrollieren, welche Programme welche Bibliotheken finden. Wird die Umgebungsvariable LD_LIBRARY_PATH in einem Shell Script vor Programmstart gesetzt wird, gilt sie auch nur dort und nicht für das ganze System.
  • Beim late binding gibt das Programm zur Laufzeit dem Betriebssystem mit, welche Bibliotheken geladen werden soll. Da das Programm selbst die Anweisungen dazu gibt, muss das early binding bereits abgeschlossen sein und das Program läuft bereits. Die Funktionen dazu sind LoadLibrary() und GetProcedureAddress(). Dieses Verfahren erlaubt ein granulares Fehlerhandling durch den Programmierer (andere Orte/Bibliotheken/Versionen der selben Bibliothek suchen/ausprobieren), ist in der Programmierung aber deutlich aufwändiger. Es bietet sich daher bei optionalen Bibliotheken oder Plugins an.