https://wiki-de.moshellshocker.dns64.de/index.php?action=history&feed=atom&title=Linker_%28Computerprogramm%29Linker (Computerprogramm) - Versionsgeschichte2026-05-18T10:50:35ZVersionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale KopieMediaWiki 1.43.8https://wiki-de.moshellshocker.dns64.de/index.php?title=Linker_(Computerprogramm)&diff=48758&oldid=prev~2025-43743-75: /* Weblinks */ Wie Compiler und Linker arbeiten, mal ein ordentlicher Artikel, in dem Details zum Linken ausführlich erklärt werden und was auch als Quellenbeleg dienen könnte um den Artikel zu verbessern.2025-12-30T00:54:15Z<p><span class="autocomment">Weblinks: </span> Wie Compiler und Linker arbeiten, mal ein ordentlicher Artikel, in dem Details zum Linken ausführlich erklärt werden und was auch als Quellenbeleg dienen könnte um den Artikel zu verbessern.</p>
<p><b>Neue Seite</b></p><div>[[Datei:Linker.svg|mini|200px|[[Bibliothek (Programmierung) #Statische Bibliotheken|(Statische) Bibliotheken]]&nbsp;(lib) und/oder Objektdateien&nbsp;(obj) werden vom Linker zu Bibliotheken, [[Bibliothek (Programmierung) #Dynamische Bibliotheken|Dynamischen Bibliotheken]]&nbsp;(dll) oder [[Ausführbare Datei|ausführbaren Dateien]]&nbsp;(exe) zusammengefügt (gelinkt).]]<br />
Unter einem '''Linker''' oder '''Binder''' (auch: '''Bindelader''') versteht man ein [[Computerprogramm]], das einzelne [[Modul (Software)|Programmmodule]] zu einem ausführbaren Programm zusammenstellt (verbindet). Auf [[IBM]]-[[Großrechner]]systemen wird der Linker ''linkage editor'' (englisch) genannt.<ref>{{Literatur |Hrsg=IBM Corporation |Titel=Operating System 360, Linkage Editor, Program Logic Manual |Ort=New York |Datum=1967}}</ref><br />
<br />
Die meisten Programme enthalten Bestandteile oder Module, die in anderen Programmen verwendet werden können. Mehrere [[kompiliert]]e Module mit [[Funktion (Programmierung)|Funktionen]] (''Objektdateien'') können zu Funktionsbibliotheken (''[[Programmbibliothek]]en'') zusammengefasst werden. Der [[Quelltext|Code]] wird durch den Linker zum Hauptprogramm hinzugefügt, falls die entsprechende Funktion benötigt wird.<br />
<br />
Um ein Programmmodul in einem anderen Programm verwenden zu können, müssen die symbolischen Adressen der Funktionen und [[Variable (Programmierung)|Variablen]] des Moduls in [[Speicheradresse]]n umgewandelt werden. Diese Aufgabe übernimmt der Linker. Der Linkvorgang erfolgt nach der [[Kompilierung]] und ist meistens der letzte Arbeitsschritt zur Erstellung eines Programms.<br />
<br />
== Statisches Linken ==<br />
Das ''statische Linken'' erfolgt typischerweise am Ende der [[Softwareentwicklung|Entwicklung des Programms]]. Das Ergebnis ist ein fertig zusammengesetztes Programm, das bei vollständig statisch gelinkten Programmen aus einer einzigen [[Datei]] besteht.<br />
<br />
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 (Informatik)|Laufzeit]] geschieht.<br />
<br />
Ein Vorteil ist beim statischen Linken die erhöhte [[Portable Software|Portabilität]] einer Anwendung, da diese ''nicht'' auf die Bereitstellung von Programmmodulen z.&nbsp;B. durch das [[Betriebssystem]] angewiesen ist, da die Anwendung diese selbst mitführt; eine [[Installation (Computer)|Installation]] des Programms ist somit nicht erforderlich.<ref>[http://www-vs.informatik.uni-ulm.de/teach/ss10/bs/docs/BS_D1_12_Hauptspeicher.pdf Kapitel über Hauptspeicher, Folie 6] (PDF) informatik.uni-ulm.de ''Betriebssysteme'' – Vorlesung im Hauptstudium</ref> 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 (Software)|Version]] herausgegeben wurde.<ref name="drepper">{{cite web|url=http://people.redhat.com/drepper/no_static_linking.html|archiveurl=https://web.archive.org/web/20041221091001/http://people.redhat.com/drepper/no_static_linking.html|archivedate=2004-12-21|title=Static Linking Considered Harmful|author=[[Ulrich Drepper]]|quote=''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. […]''|publisher=redhat.com|language=englisch|accessdate=2012-01-13}}</ref><br />
<br />
Wegen dieser Nachteile unterstützen einige [[C (Programmiersprache)|C]]-Bibliotheken unter [[Unixoides Betriebssystem|Unix-artigen Betriebssystemen]] das statische Linken oft nicht mehr vollständig.<ref name="drepper" /> So erzwingt beispielsweise die&nbsp;[[glibc]] ein dynamisches Linken bei Modulen, die die Benutzer[[authentifizierung]] betreffen. Programme, die diese Module verwenden, sind immer auf die Anwesenheit einer passenden „Laufzeitversion“ der&nbsp;glibc angewiesen.<br />
<br />
== Dynamisches Linken ==<br />
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 [[Programmbibliothek#Dynamische Bibliotheken|''dynamischer Bibliotheken'']] (auch bekannt als ''[[Dynamic Link Library|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.&nbsp;B. [[DLL-Konflikt]]). Nachgeladene Bibliotheken werden oft als [[Plug-in]]s bezeichnet.<br />
<br />
Mischformen der statischen und dynamischen Link-Art sind der Normalfall. Dabei werden gewisse Unterprogramme dem aufrufenden Programm statisch hinzugebunden, andere werden dynamisch nachgeladen.<br />
<br />
== Sprachspezifische Varianten beim Laden ==<br />
=== Überladen ===<br />
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.<br />
<br />
Die Funktion <code>void function(int x);</code> ist eine gänzlich andere als <code>void function(float x);</code>. Beide Funktionen haben verschiedene Implementierungen, verschiedene Bezeichnungen in der [[Objektcode|Objektdatei]] und haben nichts weiter miteinander zu tun, als dass sie den gleichen Namen tragen. Überladen ist also nur der Funktionsname.<br />
<br />
Problematisch für das Verständnis und für den Übersetzer sind Aufrufe folgender Art:<br />
<br />
<syntaxhighlight lang="C"><br />
short y;<br />
function(y);<br />
</syntaxhighlight><br />
<br />
Hier muss der Übersetzer entscheiden, ob er eine [[Typumwandlung]] (''cast'') nach <code>int</code> oder nach <code>float</code> 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 <code>function((float)(y));</code> per Typumwandlung festlegen.<br />
<br />
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 (Programmierung)|Vererbung]]) ableitbar sind, bezeichnet werden. Hier prüft der Übersetzer jedenfalls die Zeigertyprichtigkeit und meldet entweder einen Fehler oder verwendet genau das passende Unterprogramm:<br />
<br />
<syntaxhighlight lang="Cpp"><br />
class ClassA;<br />
class ClassB;<br />
function(class A*); // Ist deutlich unterschieden von<br />
function(class B*);<br />
</syntaxhighlight><br />
<br />
wenn ClassA und ClassB in keiner Weise voneinander abgeleitet (vererbt) sind.<br />
<br />
=== Überschreiben ===<br />
Mit dem vom „Überladen“ zu unterscheidenden „[[Überschreiben (OOP)|Überschreiben]]“ wird ein [[Dynamische Bindung|dynamisches Binden]] bezeichnet, das im Programmablauf entsprechend reagiert, wenn im Quelltext eine Methode (d.&nbsp;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 [[Objektorientierte Programmierung|objektorientierter Programmierung]].<br />
<br />
== Namenskonflikte ==<br />
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.&nbsp;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 [[Suchpfad]]e 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.<br />
<br />
== Literatur ==<br />
* {{Literatur<br />
|Autor=Leon Presser, John R. White<br />
|Titel=Linkers and Loaders<br />
|Sammelwerk=ACM Computing Surveys<br />
|Band=Bd. 4<br />
|Nummer=3 (Sept.)<br />
|Ort=New York<br />
|Datum=1972<br />
|ISSN=0360-0300<br />
|Seiten=149–167<br />
|Online=http://inst.eecs.berkeley.edu/~cs162/sp06/hand-outs/p149-presser-linker-loader.pdf<br />
|Format=PDF<br />
|KBytes=1300}}<br />
* {{Literatur<br />
|Autor=John R. Levine<br />
|Titel=Linkers and Loaders<br />
|Verlag=Morgan-Kauffman<br />
|Ort=San Francisco<br />
|Datum=1999<br />
|ISBN=1-55860-496-0}}<br />
* {{Literatur<br />
|Autor=Stanley B. Lippman<br />
|Titel=C++ Primer<br />
|Verlag=Addison-Wesley Longman<br />
|Ort=Amsterdam<br />
|Datum=2005<br />
|ISBN=0-201-72148-1}}<br />
* {{Literatur<br />
|Autor=Randal E. Bryant, David R. O'Hallaron<br />
|Titel=Computer Systems: A Programmer's Perspective (3. Auflage, insb. Kapitel 7)<br />
|Verlag=Pearson<br />
|Ort=Boston<br />
|Datum=2016<br />
|ISBN=978-0-13-409266-9}}<br />
<br />
== Weblinks ==<br />
* [http://www.lurklurk.org/linkers/linkers.html Beginner's Guide to Linkers]<br />
* [https://www-user.tu-chemnitz.de/~heha/hs/linker.htm Wie Compiler und Linker arbeiten]<br />
<br />
== Einzelnachweise ==<br />
<references /><br />
<br />
{{Normdaten|TYP=s|GND=4145562-9}}<br />
<br />
[[Kategorie:Programmierwerkzeug]]</div>~2025-43743-75