Library

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

--Robi 12:55, 26. Okt 2006 (CEST)

diesen Beitrag bitte mit einarbeiten http://www.linux-club.de/viewtopic.php?t=70347

Library

Was ist ein Library

Unter Library (Bibliothek) versteht man eine Sammlung von universell einsetzbaren Softwarebausteinen. Somit muss bei der Entwicklung nicht jede Funktion in jedem Programm wieder neu erfunden oder neu geschrieben werden, sondern man nutzt bei der Erstellung der Software schon fertig erprobte Funktion einer solchen Library. Zur Erstellung neuer Funktionen können somit Librarys mit fundamentalen Funktionen benutzt werden, und mehrere thematisch und logisch zusammenhängende neue Funktionen wiederum zu einer neuen Library zusammengestellt werden. Somit entstehen Hierarchien von Libraries und bei der Programmentwicklung kann man sich auf die Entwicklung des wirklich Neuem oder Einmaligem beschränken.

verschieden Typen von Library

Man unterscheidet :

Quelltextbibliotheken 

enthalten Sammlungen von Wertedefinitionen, Deklarationen, Funktionen, Klassen, generischen Bestandteilen, usw. In diesen Libraries befindet sich Quelltext in irgend einer Programmiersprache. Oftmals werden solche Bibliotheken genutzt um die Schnittstellen und Definitionen für andere Libraries zur Verfügung zu stellen. Solche Librarys werden nur während der Entwicklung und Übersetzung des Quellcodes in den ausführbaren Code benötigt. Zur Ausführung oder während der Laufzeit des fertigen Programmes werden diese Library nicht mehr benötigt.

Statische Bibliotheken 

bestehen schon aus ausführbarem Binärcode. Nach dem Kompiliervorganges des neuen Programmes, werden sie mittels eines so genannten Linker oder Binder mit dem ausführbaren Programm zu einem lauffähigem Programm vereint. Der Linker sucht aus den Bibliotheksdateien die Unterprogramme heraus, für die es im Programm keine Implementierung gibt. Diese werden dann aus den Dateien extrahiert und mit den Funktionen des Programms zu einer einzigen Datei verbunden. Man nennt das statisch gegen die Library linken. Jedes so entstandene Programm und somit auch jeder Prozess der durch das Starten eines solchen Programmes entsteht, hat also Teile der Library "im Bauch". Die Library an sich, wird zur Ausführung des Programmes nicht benötigt. Dieses Verfahren wird wegen des großen Speicherverbrauchs während der Laufzeit der Programme eher selten angewandt.

Dynamische Bibliotheken 

bestehen ebenfalls aus schon ausführbarem Binärcode. Die benötigten Objekte der Library werden aber nicht vom Linker in das neue Programm übernommen, sondern nur die Einsprungsmarke der benötigten Funktionen im Libray wird im Programm hinterlegt. Man spricht hier von dynamisch gegen die Library linken. Dynamische Bibliotheken werden bei Bedarf, also erst bei der Anforderung eines Programmes, komplett in den Arbeitsspeicher geladen und können dort von mehreren Programmen gleichzeitig genutzt werden. Dadurch muss eine Bibliothek, die von mehreren Programmen genutzt wird, nur einmal im Speicher gehalten werden, was einen bedeutenden Vorteil gegenüber statisch verlinkten Programmen bedeutet. Diese Library muss dann aber während des Startes der Programme im Linuxsystem auch verfügbar sein. Da aber mehrere Programme ein Library im Hauptspeicher benutzen können, muss die Verwaltung, das Laden und Entladen dieser Library von Linux selbst übernommen werden, und kann nicht von den Programmen selbst übernommen werden. Diese Funktion, sozusagen der dynamische Linker und Lader oder Library-Loader, erledigt in Linux ein Programm Namens ld.so .

Vor- und Nachteile von dynamischen Library

Neben dem schon angesprochenem Vorteil, daß eine Library im Speicher gleichzeitig von mehreren Programmen und Instanzen dieser Programme genutzt werden kann, was eine sehr effektive Hauptspeicherverwaltung begünstigt, gibt es noch einen riesen Vorteil gegenüber statisch verlinkten Programmen. Im Falle einer notwendigen Änderung innerhalb von Funktionen eines Libraries, muss im System nur diese Library ausgetauscht werden und nicht alle Programme, die gegen diese Library gelinkt sind, neu kompiliert und neu gelinkt werden. Den Vorteilen stehen aber auch einige Nachteile entgegen. Da eine Library zur Ausführung von Programmen oder anderen Libraries in einem System immer vorhanden sein muss, entstehen jede Menge Abhängigkeiten. Sicherlich hat das jeder schon einmal erlebt, und mach einer auch schon daran verzweifelt, die Installation eines neuen Programmes erfordert eine bestimmte Library und will man diese fehlende Library dann installieren, dann fordert diese Installation jetzt erstmal wiederum bestimmte Libraries usw..... Ein zweiter Nachteil wird schnell sichtbar, wenn man bedenkt, dass es nicht immer gelingt, daß neue Versionen einer Library immer 100% kompatibel zu ihrer Vorgängerversion sind. Somit muss man in einem Linuxsystem oftmals mehrere Versionen ein und des selben Library bevorraten, da die einzelnen Programm gegen bestimmte Versionen gelinkt sind und die Abhängigkeiten besagen, es muss mindestens diese Version sein, oder maximal diese Version oder genau diese Version der Library. Siehe auch hier das Problem mit der Standard-Library, die wohl wichtigste Library im System, gegen die alle anderen Libraries und Programme gelinkt sind.

Der dynamische Loader

Der dynamische Linker und Loader ld.so oder als Link darauf auch ld-linux.so ist das Programm in Linux welches die Verwaltung und das Laden der dynamischen Bibliotheken ermöglicht. Damit er selbst funktionieren kann, ist er statisch gegen die libc.so gelinkt. Damit jetzt die Libraries geladen werden können, muss folgendes geklärt sein. Welche Libraries stehen zum laden im System zur Verfügung, in welchen Verzeichnissen liegen diese oder müssen dazu durchsucht werden. Der ld.so hat also eine Konfiguration. Diese befindet sich in der Datei /etc/ld.so.conf und ist einfach aufgebaut. In ihr werden die Verzeichnisse eingetragen, in denen die Libraries zu finden sind. (die beiden Standard Verzeichnisse /lib und /usr/lib brauchen nicht mit angegeben werden). Daneben gibt es noch einige Variablen, in denen Verzeichnisse für Libraries eingetragen werden können, damit ld.so diese laden kann, das wird aber in aller Regel nur in Ausnahmefällen benötigt, wenn zB. eine neue Version eines Library getestet werden soll, anstatt dem, was normal auf dem Rechner installiert ist, siehe dazu die Manpage von ld.so Damit jetzt nicht bei jeder Anforderung eines Programmes das halbe System nach der Library durchsucht werden muss, wird eine Datenbank (cache) geführt, in der die vorhandenen Libraries mit ihrem Path eingetragen sind. Dieser Cache befindet sich in der Datei /etc/ld.so.cache. Das Programm das diesen Cache anlegt, aktualisiert und mit dessen Hilfe man auch den Inhalt anzeigen kann ist ldconfig.

Damit nun eine neu hinzugekommene Library von ld.so automatisch geladen werden kann, muss sie also zuerst einmal mit ldconfig in den cache eingetragen werden. Die Benutzung von ldconfig obliegt nur root. Wird als root der Befehl abgegeben (ohne irgendwelche Optionen) wird anhand der /etc/ld.so.conf die Verzeichnisse nach Libraries durchsucht und in die /etc/ld.so.cache eingetragen. Mit ldconfig -p kann man sich auch den Inhalt der /etc/ld.so.cache in lesbarer Form anzeigen lassen.

Namen und Verzeichnisse der Library

Jede Bibliothek braucht selbstverständlich auch einen eindeutigen Namen. So heißt beispielsweise

• die Standard Bibliothek beispielsweise c
• die Library mit den Mathematikfunktionen heißt einfach m
• die Library für das dynamische Laden heißt dl

Auch wenn kurze Namen in aller Regel mal nicht schlecht sind, hier muss man im Namen noch etwas davor stellen, damit man auch erkennt, dass es sich um ein Library handelt, also wird den Namen die Silbe lib vorangestellt. So entstehen daraus die Library-Name libc libm libdl. Hinter diesem Namen folgt jetzt abgetrennt mit einem Punkt noch eine Erweiterung.

• ( .so ) (engl.: shared object) für dynamische Library
• ( .a ) (engl.: archive) für statische Library

und daran gegebenenfalls noch anschließen die Kennung der genauen Version dieser Library.

Am besten sehen wir das am Beispiel:

 
robi@LINUX:/usr/lib> ls -l  liba52.*
-rw-r--r--  1 root root 104658 2004-11-28 00:49 liba52.a
-rwxr-xr-x  1 root root    697 2004-11-28 00:49 liba52.la
lrwxrwxrwx  1 root root     15 2006-05-21 14:21 liba52.so -> liba52.so.0.0.0
lrwxrwxrwx  1 root root     15 2006-05-21 14:21 liba52.so.0 -> liba52.so.0.0.0
-rwxr-xr-x  1 root root  91103 2004-11-28 00:49 liba52.so.0.0.0
robi@LINUX:/usr/lib> file  liba52.*
liba52.a:        current ar archive
liba52.la:       ASCII English text
liba52.so:       symbolic link to `liba52.so.0.0.0'
liba52.so.0:     symbolic link to `liba52.so.0.0.0'
liba52.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 

Es sind hier also die Dateien der Library a52 zu sehen.

• die Datei liba52.a ist die statisch Library
• die Datei liba52.so.0.0.0 ist die dynamische Library
• die Datei liba52.la beinhaltet auch für uns lesbar spezielle Link Informationen für den Linker und Loader
• liba52.so und liba52.so.0 sind Symbolische Links auf das dynamische Library.

Die genaue Benennung ist demnach liba52 Version 0.0.0

Die Library haben somit Versionsnummer im Dateinamen, aber Programme sind in der Regel gar nicht an einer bestimmten Version interessiert. Deshalb gibt es die symbolische Links.

Im obigem Beispiel kann ein Programm gegen liba52.so gelinkt werden, und wird auf die installierte Version liba52.so.0.0.0 umgeleitet. Wir eine neue Version dieser Library installiert, dann wird der Link liba52.so auf die neue Version gesetzt und das Programm kommt automatisch in den Genuss der neuen Version.

Natürlich ist es auch möglich, ein Programm gegen genau eine bestimmte Version zu linken, genau diese Version muss dann aber vorhanden sein, um das Programm zu starten. Dies ist mitunter sogar beabsichtigt, kann aber bei Updates auch zu Problemen führen, weil die Programme plötzlich nicht mehr starten oder mit Fehlermeldung abbrechen. Nun könnte man in einigen Fällen hier einfach manuell eingreifen und einfach die Links per Hand erzeugen oder anpassen, um somit Versionabhängigkeiten zu beseitigen. Das sollte man aber dringendst unterlassen, wenn man nicht genau weiß, was man hier macht und welche Auswirkungen das haben könnte.

Die Library befinden sich hauptsächlich in folgenden Verzeichnissen

• /lib alle Libraries die schon beim Start von Linux benötigt werden
• /usr/lib viele oder die meisten Libraries der Anwenderprogramme
• /usr/local/lib Libraries local installierter Programme
• /opt/kde3/lib die Libraries von KDE Programmen
• /opt/gnome/lib die Libraries von Gnome Programmen
• /opt/X11R6/lib die Libraries von X11-Programmen.

siehe auch dazu /etc/ld.so.conf die Konfigurationsdatei von ld.so

Welche Library braucht welches Programm

Gelegentlich, ist es wichtig herauszufinden welche Libraries ein Programm oder eine andere Library selbst benötigt, oder von welcher sie abhängig ist. Dieses kann man mit dem Befehl ldd. Dazu wird einfach ldd mit dem vollem Path des Programmes oder der Library aufgerufen. Und in der Ausgabe erscheinen die Abhängigkeiten von den Libraries.

robi@LINUX:~> ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000)
        libhistory.so.4 => /lib/libhistory.so.4 (0x4005a000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x40061000)
        libdl.so.2 => /lib/libdl.so.2 (0x400a7000)
        libc.so.6 => /lib/tls/libc.so.6 (0x400aa000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Libraries und Programme mit Libraries manuell installieren und aktualisieren

Grundsätzlich ist es immer besser Programme über die vorgesehenen Paketinstallationsprogramme (Smart , APT , YAST) zu installieren. In einigen wenigen Ausnahmefällen, wenn zB dieses Programm oder die spezielle Version davon, nirgends als Paket zur Verfügung steht, oder wenn das Programm mit speziellen Optionen benötigt wird, kommt man nicht drumherum das Programm manuell aus dem Quellcode selbst zu kompilieren.

Hierbei bekommt man jetzt die vollen Abhängikeiten der Programme von den Libraries besonders deutlich zu spüren. Der configure versucht die benötigten Library anzusprechen, und bricht mit Fehlermeldung ab, wenn das Library nicht vorhanden oder nicht geladen werden kann. Bei manuellen Installationen von Programmen mit Libraries muss also erst einmal ein ldconfig gemacht werden, damit ld.so das Library laden kann.

Bei der manuellen Installation gerät man leicht in eine Falle. Wird das Programm oder Library nur mit make install installiert, dann ist das Programm zwar installiert, doch wenn Programme jetzt mit dem Paketmanagern installiert werden sollen, die Abhängigkeiten zu den so manuell installierten Libraries haben , dann werden diese Libraries wiederum als fehlend an gemeckert, oder vom einem intelligentem Paketmanager noch einmal neu installiert. Das liegt daran, dass sich der Paketmanager darauf verlässt, dass immer jede Installation in die Datenbank des Paketmanagers eingetragen wird, und genau das macht make install nicht. Ist die manuelle Installation also nicht in der Datenbank des Paketmanagers vermerkt, kann der Paketmanager bei nachfolgenden Installationen/Deinstallationen die Abhängigkeiten nicht richtig erkennen oder auflösen.

Abhilfe schafft hier ein Programm namens checkinstall mit dessen Hilfe man ein manuell kompiliertes Programm als rpm-Paket installieren kann. Da das Programm dann letztendlich mit rpm installiert wird, wird auch gleich automatisch noch die /etc/ld.so.cache aktualisiert. Wird ein Programm oder manuelle erzeugten Library so installiert, dann können die Abhängigkeiten bei nachfolgenden Installationen vom Paketmanager richtig aufgelöst werden.

Und noch einen Vorteil hat die Nutzung von checkinstall, man kann durch Deinstallation des Paketes das Programm oder die Library auch wieder vollständig entfernen.

weiter Befehle rund um Libraries

--Robi 12:55, 26. Okt 2006 (CEST)