Abseits der Computer-Welt kennt die Institution namens Bibliothek jeder – wenn auch viele sie selten betreten. Der Alltag eines jeden PC-Benutzers wäre ohne Bibliotheken jedoch nicht so leicht zu bewältigen.

Über das Fragment lib im Namen von Programmpaketen stolpert man häufig. Es kürzt das Wort Libraries (englisch für “Bibliotheken”) ab. Oft tauchen sie bei der Installation neuer Programme in der Liste der benötigten zusätzlichen Pakete auf (Abbildung 1).

Abbildung 1: Praktisch jedes Linux-Programm baut auf eine große Zahl geteilter Bibliotheken.

Freundlicher Bibliothekar

Moderne Paket-Manager kümmern sich darum, dass bei der Installation einer Anwendung auch die benötigten Libraries auf der Festplatte landen. Das gilt für Debians APT und Suses Yast ebenso wie für die Werkzeuge anderer Distributionen. Häufig führt dadurch der unbedarfte Klick auf einen Installieren-Button zu einer großen Zahl neuer Pakete, die auf den ersten Blick unnötig scheinen.

Diese Pakete enthalten so genannte Shared Libraries – gemeinsame Bibliotheken. Sie stellen lediglich Funktionen bereit, auf die Anwendungen zurückgreifen. Die bedeutendste Shared Library unter Linux ist die GNU C Library (GLibC) [1]. Sie sorgt für die wichtigsten Systemfunktionen. Der Linux-Kernel selbst sowie die meisten anderen C-Programme verwenden diese Bibliothek.

Das erspart den Programmierern, die bereits durch die Bibliothek bereitgestellten Funktionen selbst neu entwickeln zu müssen. Das gilt nicht nur für systemnahe Bereiche wie bei der GLibC: Desktop-Umgebungen wie KDE oder Gnome basieren auf umfangreichen Bibliothekensammlungen. Die jeweilige Grafikbibliothek – KDE verwendet Qt [2], Gnome die Alternative GTK [3] – bringt die Fenster auf die grafische Oberfläche. Multimediabibliotheken bieten Funktionen zum Abspielen von Video- oder Audiodateien an, weitere Shared Libraries übernehmen zahlreiche andere Standardaufgaben.

Daraus entstehen die so genannten Paketabhängigkeiten. Ein Programm, das Funktionen externer Bibliotheken nutzt, wird ohne diese nicht korrekt arbeiten. Ein KDE-Audioplayer benötigt beispielsweise neben den KDE-Basisbibliotheken die Multimedia-Libraries der Oberfläche; der Programmierer braucht sich dann nicht näher um das Dekodieren und die Ausgabe einer MP3-Datei zu kümmern. Deshalb speichern die Entwickler beim Bauen eines RPM- oder Debian-Pakets eine Liste der benötigten Bibliotheken in den Paketdaten. Der Paketmanager der Distribution weiß dann, welche Bibliotheken er zusätzlich installieren muss, wenn der Benutzer besagtes Paket anfordert.

Wer ein Programme nicht über den Paketmanager installiert, sondern es aus den Quellen kompiliert, muss sich selbst um die benötigten Libraries kümmern. Er braucht jedoch zusätzlich die so genannten Entwicklerpakete. Sie enthalten die Header-Dateien, die die Funktionen der Bibliothek beschreiben. Die Entwicklerpakete enden üblicherweise auf -devel oder -dev. In Ausnahmefällen enthält das Paket einer Bibiliothek bereits die Header-Dateien, ein devel-Paket existiert dann nicht.

Welche Libs?

Meist nimmt der Benutzer die Bibliotheken kaum wahr. Die Anwendungen greifen umstandslos auf die Dateien zu, die gewöhnlich auf das Suffix .so enden. Häufig ist ein .so-Eintrag im Bibliothekenverzeichnis nur ein symbolischer Link auf die eigentliche Library-Datei, deren Name durch die Versionsnummer erweitert wird.

So findet man im Verzeichnis /usr/lib/ beispielsweise einen Link libz.so, der auf die Datei libz.so.1.2.2 verweist. Ein weiterer Link auf libz.so.1.2.2 heißt z. B. libz.so.1. Diese Methode stellt sicher, dass einerseits jedes Programm, das die Bibliothek ZLib braucht, sowohl bei der Suche nach libz.so als auch nach libz.so.1 fündig wird. Gleichzeitig liegt nur eine Bibliotheksdatei – in diesem Beispiel libz.so.1.2.2 – wirklich im Verzeichnis. Der Dateinamen verrät auf den ersten Blick die installierte Version.

Der Befehl ldd offenbart, welche Bibliotheken eine Anwendung verwendet. Das Kommando, gefolgt vom kompletten Pfad des fraglichen Programms, gibt die gesuchte Bibliothek und den genauen Ort im Dateisystem aus, an dem es sie gefunden hat:

$ ldd /bin/ls
librt.so.1 => /lib/tls/i686/?
  cmov/librt.so.1 (0xb7fd0000)
libacl.so.1 => /lib/?
  libacl.so.1 (0xb7fca000)
libc.so.6 => /lib/tls/i686/cmov/?
  libc.so.6 (0xb7e9d000)
libpthread.so.0 => /lib/tls/?
  i686/cmov/libpthread.so.0 ?
  (0xb7e8c000)
/lib/ld-linux.so.2 => /lib/?
  ld-linux.so.2 (0xb7feb000)
libattr.so.1 => /lib/?
  libattr.so.1 (0xb7e88000)

In Klammern meldet ldd die Speicheradresse der Bibliothek. Der Parameter -v für verbose (“ausführlich”) zeigt weitere Details über die einzelnen Bibliotheken.

Hilfreich ist dieses Kommando besonders bei der Fehlersuche. Steht in der ldd-Ausgabe hinter dem Pfeil bei einer Bibliotheken not found, wird das Programm nicht funktionieren, da es eine Shared Library nicht findet. Die Lösung besteht in der Installation des entsprechenden Programmpakets. Bei fertigen Bibliothekspaketen tritt dies jedoch nur dann auf, wenn der Paketerzeuger die Abhängigkeiten falsch oder unvollständig angegeben hat.

Bei selbstkompilierten Programmen kann es passieren, dass man nach der Installation benötigte Bibliotheken versehentlich wieder deinstalliert, da der Paketmanager nur auf die Abhängigkeiten zu RPM- bzw. Debian-Pakete achtet. Dann gibt die Recherche via ldd Aufschluss über die fehlende Bibliothek.

Alles im Kopf

Es würde zu lange dauern, wenn alle Programme bei jedem Zugriff auf eine Bibliothek das gesamte Dateisystem durchsuchen müssten. Deshalb enthält die Datei /etc/ld.so.cache eine Liste der bekannten Bibliotheken mitsamt ihrem Speicherort auf der Festplatte.

Nach der Installation neuer Bibliotheken muss dieser Zwischenspeicher aufgefrischt werden, damit die Programme die neuen Libraries finden. Ein Paketmanager erledigt dies selbständig, bei manueller Installation dient dazu der Befehl ldconfig. Er durchsucht die Verzeichnisse /lib/ und /usr/lib/ sowie deren Unterverzeichnisse.

Zum Auffrischen von /etc/ld.so.cache benötigt man Root-Rechte. Der Parameter -v zeigt während dieses Vorgangs alle gefundenen Bibliotheken an, ansonsten wird der Cache stillschweigend aktualisiert.

Weitere zu durchsuchende Bibliothekspfade gibt Root in der Konfigurationsdatei /etc/ld.so.conf an. Alternativ speichert man in der Umgebungsvariable LD_LIBRARY_PATH analog zur PATH-Variable eine durch Doppelpunkte getrennte Liste zu durchsuchender Pfade.

Mittels der Umgebungsvariablen LD_PRELOAD oder der Datei /etc/ld.so.preload überschreibt man Funktionen einer Shared Library. Die Funktionen der hier aufgeführten Bibliotheksdateien haben Priorität und eignen sich somit, um einzelne neue Features einzubringen.

Pakete im Eigenbau

In den Bibliotheken steckt meist das Hauptproblem beim Kompilieren von Programmen, die nur im Quellcode vorliegen. Die Installationsanleitung listet üblicherweise die benötigten Programme und Bibliotheken auf. Zum Kompilieren benötigt man die Entwicklervarianten dieser Pakete. Sind sie installiert, überprüft das Kommand ./configure, ob das System entsprechend vorbereitet ist. Gibt ./configure eine Fehlermeldung aus, lässt sich aus ihr entnehmen, woran es hapert. Fehlt ein Paket, wird es nachinstalliert und ./configure erneut gestartet.

Leider enthalten viele Quellpakete unzuverlässige ./configure-Skripte, die nicht alle Mängel erkennen. Sie geben grünes Licht, obwohl möglicherweise eine benötigte Bibliothek fehlt. Dann lässt sich der Kompiliervorgang einleiten, bricht aber mit einer oft wenig aussagekräftigen Fehlermeldung ab.

Ungeteilt

Die Alternative zur Verwendung von Shared Libraries bildet das feste Einbinden aller Bibliotheksdateien. In diesem Fall bezeichnet man ein Programm als “statisch gelinkt” (Englisch: statically linked). Es verlässt sich dann nicht darauf, dass es alle benötigten Bibliotheken vorfindet, sondern bringt sie selbst mit. Das vergrößert das Programmpaket oft um ein Vielfaches, macht es aber weitgehend unabhängig vom umgebenden System. Ein statisch gelinktes Programm empfiehlt sich, wenn man es beispielsweise auf einem tragbaren Medium speichern und auf verschiedenen Rechnern ausführen möchte.

Außer der Größe hat diese Statik einen weiteren Nachteil. Von Verbesserungen dynamischer Bibliotheken, wie gesteigerter Performance, profitiert ein statisch gelinktes Programm erst, nachdem es neu mit der neuen Version der Bibliothek kompiliert wurde. Ein dynamisch gelinktes Programm, das geteilte Bibliotheken verwendet, benutzt eine neue Version einer Bibliothek sofort.

Offene Büchereien

Das Prinzip der Shared Libraries macht in der Open-Source-Welt besonders viel Sinn. Denn jedes beliebige Programm kann eine freie Bibliothek nach Gutdünken verwenden. Die Windows-Pendants zu den so-Dateien enden auf dll und haben denselben Zweck. Unter dem Microsoft-Betriebssystem sind die meisten Programme aber statisch gelinkt oder bringen ihre eigenen DLL-Dateien mit; zum allgemeinen Einsatz gibt es hier nur systemnahe Funktionen. Unter Linux bilden die zahlreichen freien Bibliotheken dagegen die Grundlage für das Betriebssystem selbst sowie die meisten seiner Anwendungen.