Statisch oder dynamisch?

Ü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.