Linker (Computerprogramm)

Unter einem Linker oder Binder (auch: Bindelader) versteht man ein Computerprogramm, das einzelne Programmmodule zu einem ausführbaren Programm zusammenstellt (verbindet). Auf IBM-Großrechnersystemen wird der Linker linkage editor (englisch) genannt.^[1]

Die meisten Programme enthalten Bestandteile oder Module, die in anderen Programmen verwendet werden können. Mehrere kompilierte Module mit Funktionen (Objektdateien) können zu Funktionsbibliotheken (Programmbibliotheken) zusammengefasst werden. Der Code wird durch den Linker zum Hauptprogramm hinzugefügt, falls die entsprechende Funktion benötigt wird.

Um ein Programmmodul in einem anderen Programm verwenden zu können, müssen die symbolischen Adressen der Funktionen und Variablen des Moduls in Speicheradressen umgewandelt werden. Diese Aufgabe übernimmt der Linker. Der Linkvorgang erfolgt nach der Kompilierung und ist meistens der letzte Arbeitsschritt zur Erstellung eines Programms.

Das statische Linken erfolgt typischerweise am Ende der Entwicklung des Programms. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen Datei besteht.

Beim statischen Linken werden die Programmmodule der Anwendung einmalig zur Übersetzungszeit aufgelöst, im Gegensatz zum dynamischen Linken, bei dem dies jedes Mal zur Laufzeit geschieht.

Ein Vorteil ist beim statischen Linken die erhöhte Portabilität einer Anwendung, da diese nicht auf die Bereitstellung von Programmmodulen z. B. durch das Betriebssystem angewiesen ist, da die Anwendung diese selbst mitführt; eine Installation des Programms ist somit nicht erforderlich.^[2] Nachteile sind ein potentiell höherer Speicherbedarf, da Programmmodule nicht von anderen Programmen mitverwendet werden können, und die Notwendigkeit, die Gesamtanwendung neu zu kompilieren und zu linken, falls für ein Teilmodul eine verbesserte Version herausgegeben wurde.^[3]

Wegen dieser Nachteile unterstützen einige C-Bibliotheken unter Unix-artigen Betriebssystemen das statische Linken oft nicht mehr vollständig.^[3] So erzwingt beispielsweise die glibc ein dynamisches Linken bei Modulen, die die Benutzerauthentifizierung betreffen. Programme, die diese Module verwenden, sind immer auf die Anwesenheit einer passenden „Laufzeitversion“ der glibc angewiesen.

Es ist auch möglich, das Auflösen der Funktions- und Variablennamen zu verschieben, bis das Programm tatsächlich ausgeführt wird. In diesem Fall spricht man von dynamischem Linken. Je nach Betriebssystem geschieht dies durch das Laden vollständiger dynamischer Bibliotheken (auch bekannt als Dynamic Link Library (DLL) oder shared library) oder das gezielte Laden eines Unterprogramms aus einer Programmbibliothek. Dies hat den Vorteil, dass Bibliotheken oder Programme nachträglich leicht ausgetauscht werden können, die aufrufenden Programme kleiner werden und der Speicher nur einmal benötigt wird, wenn mehrere Programme dieselben Komponenten verwenden. Der Nachteil besteht darin, dass sichergestellt werden muss, dass die richtige Bibliothek in der richtigen Version installiert ist (siehe z. B. DLL-Konflikt). Nachgeladene Bibliotheken werden oft als Plug-ins bezeichnet.

Mischformen der statischen und dynamischen Link-Art sind der Normalfall. Dabei werden gewisse Unterprogramme dem aufrufenden Programm statisch hinzugebunden, andere werden dynamisch nachgeladen.

Unter „Überladen“ wird das mehrfache Definieren eines Unterprogramms mit gleichem Bezeichner in Abhängigkeit von der Parameterauswahl verstanden, realisiert durch interne Umbenennung (engl. name mangling). Die nachstehenden Beispiele sind nur in C++ oder Java möglich, nicht aber in reinem C, wo die Überladung von Funktionen nicht vorgesehen ist und der Versuch, eine solche zu verlangen, einen Übersetzungsfehler auslösen würde.

Die Funktion void function(int x); ist eine gänzlich andere als void function(float x);. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der Objektdatei und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.

Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art:

short y;
function(y);

Hier muss der Übersetzer entscheiden, ob er eine Typumwandlung (cast) nach int oder nach float durchführt und die entsprechende Variante der Funktion aufruft. Naheliegend wäre der erste Fall, dennoch hängt hier einiges vom verwendeten Übersetzer ab; der Programmierer ahnt nicht, was sich im Untergrund des Maschinencodes tut. Einige Übersetzer wählen in solchen Fällen das mutmaßlich Richtige (was im konkreten Fall falsch sein kann), andere Übersetzer, beispielsweise GNU, neigen eher dazu, einen Fehler auszugeben, um vom Anwender eine Entscheidung zu verlangen. Er muss die Auswahl dann mit einer Schreibweise wie function((float)(y)); per Typumwandlung festlegen.

Im Allgemeinen ist es besser, die Möglichkeit des Überladens nicht zu frei zu nutzen, sondern nur für deutliche Unterschiede wie Varianten von Unterprogrammen mit unterschiedlicher Parameteranzahl. Aber auch hier führt die Kombination mit Parametern mit default-Argumenten zu Irritationen. Als sicher kann ein parametersensitiver Funktionsaufruf mit Zeigern verschiedenen Types, die nicht über Basisklassen (Vererbung) ableitbar sind, bezeichnet werden. Hier prüft der Übersetzer jedenfalls die Zeigertyprichtigkeit und meldet entweder einen Fehler oder verwendet genau das passende Unterprogramm:

class ClassA;
class ClassB;
function(class A*);  // Ist deutlich unterschieden von
function(class B*);

wenn ClassA und ClassB in keiner Weise voneinander abgeleitet (vererbt) sind.

Mit dem vom „Überladen“ zu unterscheidenden „Überschreiben“ wird ein dynamisches Binden bezeichnet, das im Programmablauf entsprechend reagiert, wenn im Quelltext eine Methode (d. h. ein Unterprogramm) einer Basisklasse von der gleichnamigen und gleich parametrisierten Methode der abgeleiteten Klasse überdeckt wird. Zur Laufzeit wird diejenige Methode gerufen, die der Instanz der Daten entspricht. Das wird durch die Tabelle virtueller Methoden ermöglicht, einem Grundkonzept der Implementation von objektorientierter Programmierung.

Bei dem Vorgang des Linkens entsteht ein einziger großer, nicht-hierarchischer, gemeinsamer Namensraum. Dadurch kommt es bei großen oder sehr verzweigten Projekten oft zu Namenskonflikten. Für diese Fälle sind weak links üblich, bei denen die Linkreihenfolge entscheidet, welches Modul wo verwendet wird. Programmiersprachen wie z. B. C++ lösen das Problem dadurch, dass Modulinhalte über hierarchisch aufgebaute Namen angesprochen werden. Ungelöst bleibt damit jedoch beispielsweise das Problem der Anwesenheit einer Bibliothek in verschiedenen Versionen; das Problem ist zum Zeitpunkt des Linkens nur dadurch lösbar, dass dem Linker je nach benötigter Bibliothek unterschiedliche Suchpfade mitgegeben werden – jede der in Frage kommenden Bibliotheken unterscheidet sich zwar von der Bezeichnung her, ist aber inhaltlich für einen Linker ununterscheidbar, da in ihr die gleichen Symbole vorhanden sind. Nach dem ersten, statischen Linken ist die Angelegenheit dagegen unproblematisch, da sich die verwendete Bibliothek von da an anhand ihres Namens aufrufen lässt.

• Leon Presser, John R. White: Linkers and Loaders. In: ACM Computing Surveys. Band 4, 3 (Sept.), 1972, ISSN 0360-0300, S. 149–167 (berkeley.edu [PDF; 1,3 MB]). 
• John R. Levine: Linkers and Loaders. Morgan-Kauffman, San Francisco 1999, ISBN 1-55860-496-0. 
• Stanley B. Lippman: C++ Primer. Addison-Wesley Longman, Amsterdam 2005, ISBN 0-201-72148-1. 
• Randal E. Bryant, David R. O'Hallaron: Computer Systems: A Programmer's Perspective (3. Auflage, insb. Kapitel 7). Pearson, Boston 2016, ISBN 978-0-13-409266-9. 

• Beginner's Guide to Linkers

1. ↑ IBM Corporation (Hrsg.): Operating System 360, Linkage Editor, Program Logic Manual. New York 1967. 
2. ↑ Kapitel über Hauptspeicher, Folie 6 (PDF) informatik.uni-ulm.de Betriebssysteme – Vorlesung im Hauptstudium
3. ↑ ^{a b} Ulrich Drepper: Static Linking Considered Harmful. redhat.com, archiviert vom Original am 21. Dezember 2004; abgerufen am 13. Januar 2012 (englisch): „There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. […]“