Diskussion:Linker (Computerprogramm)

Sprachspezifische Varianten beim Laden?

Der Abschnitt "Sprachspezifische Varianten beim Laden" befasst sich mit einem völlig anderen Thema und hat mit dem Linker nichts zu tun. Darüberhinaus ist der Titel "Sprachspezifische Varianten beim Laden" inhaltsloses Kauderwelsch. Kann ersatzlos gestrichen werden. --91.3.23.233 09:13, 5. Nov. 2024 (CET)

Weiterleitung

Ich habe eine Weiterleitung auf "Linker (Programm)" gesetzt (Ist etwas ausführlicher). Falls jemand eine Information vermissen sollte -> Dort nachtragen.

Wozu der Zusatz "Programm"? Ist eine Begriffsklärung nötig? Wenn nein, sollte man das ganze doch lieber hier positionieren... --Drumknott 15:38, 27. Apr 2004 (CEST)

Der Absatz über Unix ist ja mal großer Unfug! Bei Windows-Programmen hat man das gleiche Problem...

Und natürlich hat das Linken auch nichts mit C zu tun... Benutzer: "Unknown"

Artikelname

Wer hat denn den Linker in "Binder" umbenannt? Das ist eine ziemlich unübliche Bezeichnung. Hier verwendet man auch im Deutschen den englischen Fachbegriff "Linker". 79.196.168.42 20:23, 31. Mär. 2008 (CEST)

Ja, das sehe ich auch so. Man redet in diesem Zusammenhang ja auch selten vom “Vorverarbeiter”, “Übersetzer” oder “Zusammensteller” … (Na schön – “Binder” mag nicht vollkommen unüblich sein, aber “Linker” ist doch weitaus gebräuchlicher. Nichwa?) --131.169.184.136 21:36, 23. Apr. 2008 (CEST)

Ich bin absoluter der gleichen Meinung - schnell wieder in Linker umbenennen. Als unregistrierter User werd' ich mir daran jedoch nicht die Finger verbrennen.

Der Artikel selbst führt seinen eigenen Namen schon ad-absurdum, da im gesamten Text (wenn man mal den ersten Definitionssatz weglässt) kein einziges Mal der Begriff Binder auftaucht. Es wird immer vom Linker (5 mal) oder einer davon abgewandelten Form "link..." (25 mal) gesprochen. - 81.62.81.105 19:05, 7. Mai 2008 (CEST)

Historie ?

Ich habe den Artikel gesucht, weil ich wissen wollte, seit wann es Linker gibt, wie war die Entwicklung des Softwareengeneerings. Vermute, auf jeden Fall vor 1970 (C), aber gabs das schon bei COBOL der 50-ger? Solche Infos wären auch ganz nützlich in einer Enzyklopädie!

Das verlinkte Buch hat ein Kaptiel ueber die Historie. --Gms 11:20, 26. Jul. 2009 (CEST)

Namenskonflikte

„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.“

Verstehe ich nicht. Das Problem von Bibliotheken in verschiedenen Versionen ist ja sehr systemspezifisich (z.B. Java-Welt vs. Unix-shared-libs). Bei Unix-ähnlichen Systemen sind ja die shared-libs durchversioniert (wenn der Autor nicht schlampt) - und so kann ich auch ohne unterschiedliche Suchpfade eine bestimmte Version beim Linken angegen.

Den letzten Satz verstehe ich erst recht nicht. Denn wenn eine Lib statisch zu Programm-Object-files gelinkt wird, dann enthält das resultierende Programm doch die benötigten Code-Teile der statischen Lib in Kopie. D.h. es gibt keine 'von da an anhand ihres Namens' Aufrufe.

--Gms 11:28, 26. Jul. 2009 (CEST)

Absatz zum statischen Linken

"Das statische Linken ist ein Vorgang, der typischerweise während der Entwicklung des Programms erfolgt, nachdem der Benutzer ein fertig zusammengesetztes Programm erhält."

...

Dieser Satz ist unverständlich. Wer ist mit 'Benutzer' gemeint? Die Entwicklung eines Programms erfolgt nicht, nachdem der Benutzer (Endanwender! Nicht Entwickler.) ein fertig zusammengesetztes Programm enthält. Das möge doch bitte jemand, der sattelfest in dem Thema ist, korrigieren.

Wenn das Beispiel mit dem statischen Linken unter Linux in Bezug auf die Authentifizierungsmodule beibehalten werden soll, dann wäre eine gute Begründung sinnvoll. (nicht signierter Beitrag von 141.51.41.235 (Diskussion) 23:42, 12. Jan. 2011 (CET))

Nachtrag Kmb: Abgesehen davon ist hier etwas der Wurm drin, angefangen davon, dass es m.E. nicht 'nachdem' sondern 'bevor' heissen müsste. Ich würde umformuliert sagen:

"Das statische Linken ist ein Vorgang, der während des Build-Vorgangs zur Entwicklungszeit die symbolischen Bezeichner mit Speicheradressen ersetzt." (...)

"Dahingegen werden beim dynamischen Linken die symbolischen Bezeichner erst zur Ausführungszeit gegen tatsächliche Programmadressen ersetzt. Das Laden der Module sowie das ermitteln der Programmadressen erfolgt durch Aufruf (statisch gelinkter) Bibliotheks-Funktionen. Es werden ggf. auch Strukturen zur Verwaltung der Speicheradressen (Funktionszeiger) von geladenen Modulen (von Hand) implementiert. Bei weiterentwickelten Technologien (auch c++?) braucht dieser Code nicht mehr von Hand implementiert werden. Der Build-Prozess generiert den erforderlichen Code bzw. die Laufzeitbibliotheken der Sprache erledigen dies."

Folgenden Abschnitt bitte mit vorsicht geniessen/sehr genau prüfen: warum man nicht alles statisch linken kann: Mögliche erklärung, die aber nicht auf genanntes beispiel zutreffen muss: Weil man bei der Definition der Anforderungen für bestimmte Komponententtechnoligien schlicht auf die statische linkbarkeit verzichtet hat. Ich kenne das nur aus sehr theoretischem Ansatz: Komponenten haben oft die Prämise, selbtbeschreibend zu sein. Dies beinhaltet, dass z.b. eine Komponente (z.b. Am Anfang der Datei) Metainformationen enthält, welche Klassen/Funktionen bereitgestellt werden (=>REflection). Wenn nun die Komponente z.b in der anzahl ihrer funktionen erweitert wird, verschieben sich die Funktionsadressen weil ja die Meta-Informationen im Header umfangreicher werden. Da man verschiedene versionen einer komponente dynamisch linken können möchte macht es gar keinen sinn, eine statisches linken zu unterstützen, denn damit kann man per definition keine versionskompatibilität im gewünschten umfang zu stande bringen. Die Programmadresse wird beispielsweise erst vor dem ersten aufruf durch den JIT-Kompiler aufgelöst. Inwieweit das jetzt aber auf die Frage zutrifft - ka. Dynamisches Linken im c++ sinne könnte etwas anderes bedeuten, wie das merkmal der dynamichen linkbarkeit einer hochsprachigen komponententechnologie wie .net. mein wissen bzgl standard c++-dlls, die sich dynamisch linken lassen ist wenig bis nicht vorhanden, ich geh aber davon aus, dass in so einer dll am anfang im header eben auch die entsprechende meta info steht und o.g. beschreibung/begründung auch auf c++ - dynamic link-dlls übertragbar ist.

Vielleicht beruht das o.g. verständnisproblem darauf, dass es zwar theoretisch denkbar wäre, so eine dynamisch linkbare komponente auch statisch zu linken aber man hat es in einzelnen implementierungen bewusst deaktiviert und zum fehlerfall degradiert, einfach um die irreführenden fehler zu vermeiden, die entstehen würden, wenn man die falsche version linkt und (unsaubererweise) die versionsnummer nicht prüft. Das verhalten im fehlerfall ist nicht definierbar. all diese verantwortlichkeiten (version prüfen, programmadresse auflösen) soll eben bei der komponente liegen, damit der dienstanbieter (=multilink-dll) sich gegen falsche bedienung absichern kann.

Genau das unterscheidet ja die dynamische linking auf dem Fußweg (wie oben beschrieben) vom generischen Ansatz, der in weiterführenden Hochsprachen wie Java oder .NET implementiert ist: Implementiert man dynamisches linken von hand programmiert man LoadModule und ResolveSymbol im Anwender der bibliothek und ist selber verantwortlich für versionsprüfung. Java oder .NET generieren einen Schutzproxy, der die versionskompatibilität sicherstellt sowie die auflösung der symbole. Anfallende, unsichere void*-casts und kritische versionsprüfungen werden durch generierten code erledigt, wobei eben der generator-algorithmuss die erkennung und definierte reaktion im fehlerfall sicherstellen. Die komponente sichert sich gegen falsche bedienung ab und stellt sicher, dass es bei falscher bedienung zu definiertem fehlverhalten kommt.

Nicht ganz einfach zu verstehen, da man hier im Assemblercode fast genauso zu Hause sein muss wie in den GOF-Patterns und compiler-bau. (Etwas überspitzt ausgedrückt) (nicht signierter Beitrag von 91.11.105.171 (Diskussion) 05:27, 17. Mär. 2011 (CET))

Hoffe es hilft irgendwie. Sorry, dass es nicht spruchreif ausformuliert ist, hab einfach nicht so viel zeit und eneergie, die ich in wiki und (mein autodidaktisches) studium investiern kann.

-kmb --91.11.105.171 04:22, 17. Mär. 2011 (CET)

Links zu dynamischen Bibliotheken im Abschnitt Dynamisches Linken

Der Link hinter DLL zu Bibliothek_(Programmierung) bzw. Bibliothek_(Programmierung) scheint mir nicht obtimal zu sein. Sowie ich es verstanden habe, ist dynamische Bibliotheken der betriebsystemumabhänige deutschsprachige Oberbegriff. Insofern finde ich es sinnvoll diesen Begriff zu nennen und ihn auf Programmbibliothek#Dynamische_Bibliotheken zu verlinken. Wenn zudem noch die beiden (offenbar eher auf bestimmte Betriebssysteme bezogenen) englischspachigen Bezeichnungen verlinkt werden sollen, so würden sich Links auf Programmbibliothek#Unixartige_Systeme hinter shared library' und auf Dynamic Link Library hinter diesem Begriff anbieten. Bin aber nur Jurist und habe nur ein Buch für Juristen vorliegen, auch wenn der entsprechende Abschnitt von Informatikern geschrieben wurde (Markus Schmidt, in: Beck'sches Mandatshandbuch IT-Recht, München 2011, § 1 Randnummer 18-25, insbes. 23-25). --pistazienfresser (Diskussion) 20:37, 17. Mär. 2013 (CET)

Redundanz zu Programmbibliothek

In beiden Artikeln werden die Aspekte statisches und dynamisches Linken ziemlich identisch beschrieben, jedenfalls erkennt man keine klare Abgrenzung zwischen den beiden Lemmas. Meine Meinung: Hier bei Linker sollte i.W. stehen, was der Linker (in beiden Fällen und im Wesentlichen) TUT (wobei anzumerken wäre, dass das Laden (beim dyn. Linken) etwas anderes ist); bei Bibliothek braucht es dann eigentlich nicht mehr viel Text, das sind einfach die Objekte ('Sammlungen'), in denen die relevanten Unterroutinen gespeichert werden. Meinungen? --VÖRBY (Diskussion) 09:39, 5. Mai 2014 (CEST)

Binden und Laden (Bindelader)

Ich habe die Änderung vom August 2019, durch die die etablierten Begriffe "Binden und Laden" und "Bindelader" entfernt wurden, wieder rückgängig gemacht. Eine Enzyklopädie soll nämlich nicht nur jeweils den neuesten Stand der Technik wiedergeben, sondern auch die historische Entwicklung darstellen. Ansonsten könnte im konkreten Fall jemand, der in ein altes Buch zum Thema Softwareentwicklung schaut, den weit verbreiteten Ausdruck "Binden und Laden" nicht mehr nachschlagen. Hier ein Beispiel aus der "Neuzeit" (2009):

https://www.informatik.uni-kiel.de/~wg/Lehre/Vorlesung-SS2009/Folien_20090420.pdf Schweigstill (Diskussion) 11:06, 9. Okt. 2019 (CEST)