Im Gegensatz zu statischen Bibliotheken gibt es noch dynamische Bibliotheken, auf die wir

nun etwas eingehen wollen.

Während statische Bibliotheken im Prinzip nur ein Archiv mit mehreren Dateien sind,

sind dynamische Bibliotheken eine Funktionssammlung.

Der Unterschied ist nun, dass eine statische Bibliothek einmal beim Linken verwendet wird

und die notwendigen Teile, die aus der Bibliothek verwendet werden, direkt in das ausführbare

Programm mitkopiert werden.

Bei dynamischen Bibliotheken hingegen ist es so, dass diese nicht mehr in das ausführbare

Programm kopiert werden.

Stattdessen werden diese nachgeladen, sobald das Programm zur Ausführung kommt.

Per Konvention werden dynamische Bibliotheken ebenfalls mit dem Präfix lib gekennzeichnet,

enden aber auf das suffix.so für shared object.

Kommt nun ein Programm, das mit einer dynamischen Bibliothek gelinkt wurde zur Ausführung, so

wird das Programm in den Hauptspeicher geladen.

Außerdem werden alle dynamischen Bibliotheken, die benötigt werden, ebenfalls in den Hauptspeicher

geladen.

Dabei ist aber zu beachten, dass dies in der Regel nur einmal geschieht.

Wenn festgestellt wird, dass eine Bibliothek, die benötigt wird, bereits im Hauptspeicher

liegt, so wird die bereits vorhandene Version weiter genutzt.

Interessant ist an der Stelle aber, dass die Bibliothek zwar nur einmal im Hauptspeicher

liegt, aber an verschiedenen Stellen in den jeweiligen Adressräumen der einzelnen Prozesse

eingeblendet sein kann.

Dies ist notwendig, da es sonst zu Adresskonflikten kommen würde.

Wenn wir uns nämlich vorstellen, dass eine Bibliothek immer an genau einer Stelle liegt,

dann kann man sich schnell ein Szenario vorstellen, an dem der Platz einer Bibliothek bereits

im logischen Adressraum belegt ist.

Damit nun dynamische Bibliotheken an verschiedenen Positionen im logischen Adressraum liegen

können, muss man während des Kompilierens einige Dinge beachten.

Nämlich darf man nur positionsunabhängigen Code in Bibliotheken verwenden.

Dies lässt sich zum Glück automatisch steuern, indem man dem Übersetzer die Option b-f

pick übergibt, wobei pick für position-independent-code steht.

Übergibt man diese Option dem Übersetzer, so drückt dieser Sorge dafür, dass innerhalb

der Funktionen nicht auf absolute Adressen zugegriffen wird.

Stattdessen ist jeder Zugriff auf eine Funktion innerhalb der Bibliothek oder auf eine globale

Variable der Bibliothek immer relativ.

Dementsprechend muss jedes Modul, das Teil der Bibliothek sein soll, mit der Option f

pick kompiliert werden.

Möchte man nun aus den Objektdateien, die man so erstellt, eine dynamische Bibliothek

bilden, so kann man dies machen, indem man dem Übersetzer die Option b-shared übergibt.

In dem Beispielaufruf hier erstellen wir eine Bibliothek mit dem Namen lib-example.so.

Der Name wird durch die Option b-o vorgegeben.

Durch die Option b-shared bestimmen wir, dass aus allen angehängten Objektdateien eine

dynamische Bibliothek gebunden werden soll.

Wollen wir nun unser eigentliches Programm mit einer dynamischen Bibliothek linken, ist

der Aufruf an den Linker identisch, wie wenn wir eine statische Bibliothek verwenden.

Das heißt, wir müssen wieder die Option b-l und b-l nutzen.

Aber im Gegensatz zur statischen Bibliothek werden jetzt nicht die einzelnen ODateien

innerhalb der Bibliothek mit in das ausführbare Programm hinein kopiert, sondern es werden

nur Verweise erzeugt.

Die Verweise weisen den Lader später dazu an, die richtigen Bibliotheken mit in den