imported>BrunoBoehmler: /* Bibliotheken unter Amiga OS */ fehlende Leerzeichen ergänzt

2026-03-23T12:59:02Z

Bibliotheken unter Amiga OS: fehlende Leerzeichen ergänzt

Neue Seite

Eine '''Programmbibliothek''' (kurz '''Bibliothek'''; {{enS|library}}, kurz ''{{lang|en|lib}}'') bezeichnet in der [[Programmierung]] eine Sammlung von [[Unterprogramm]]en/-routinen, die Lösungswege für thematisch zusammengehörende Problemstellungen anbieten. Bibliotheken sind im Unterschied zu [[Computerprogramm|Programmen]] keine eigenständig lauffähigen Einheiten, sondern sie enthalten [[Modul (Software)|Hilfsmodule]], die von Programmen angefordert werden.

In erweitertem Sinn gelten als Programmbibliotheken (zum Teil auch „Komponentenbibliothek“ oder „Klassenbibliothek“ genannt) alle Arten von Bibliotheken, die Programmcode(-bestandteile) bereitstellen/enthalten. Insofern unterscheidet man Programmbibliotheken u. a. nach dem Typ des Programmcodes, z. B. Quelltexte, Makros, Object- oder Bytecode, Maschinencode usw. Dementsprechend werden Bibliotheken zu unterschiedlichen Zeitpunkten benutzt, manche nur im Rahmen der [[Softwareentwicklung]] (von Werkzeugen der [[Integrierte Entwicklungsumgebung|Entwicklungsumgebung]]), andere nur zur [[Laufzeit (Informatik)|Ausführung]] von Programmen, wieder andere als Mischform von beiden. Solche Bibliotheken enthalten häufig nicht nur Unterprogramme, sondern Programmcodeteile aller [[Computerprogramm#Klassifizierungsmöglichkeiten|Programm-Typen]].

Eine besondere Form von Programmbibliotheken sind [[Framework]]s.

== Zugriff ==
Mögliche Zugriffe auf Funktionen einer Programmbibliothek sind durch die [[Programmierschnittstelle]] (API) definiert. Dabei handelt es sich um die Gesamtheit der öffentlich verfügbaren Funktionen und Klassen; in Abgrenzung zu den privaten Einheiten der Bibliothek, die nicht zugänglich sind.

Manche [[Proprietäre Software|proprietären]] Programmbibliotheken werden nicht im [[Quelltext]] veröffentlicht, da sie Firmengeheimnisse darstellen. Zum Schutz gegen [[Decompiler|Dekompilieren]] wird dann oft ein [[Obfuskation (Software)|Obfuscator]] eingesetzt sowie alle [[Debugsymbol|Symbole]] ([[Variable (Programmierung)|Variablen]]- und [[Label (Programmierung)|Sprungadressnamen]]) entfernt.

== Speicherungsformen ==
Programmbibliotheken und ihre Inhalte können, abhängig vom Betriebssystem und der Entwicklungsumgebung, in unterschiedlichen Formen und Strukturen gespeichert werden, zum Beispiel:
* Die Bibliothek ist ein [[Verzeichnisstruktur|Dateiverzeichnis]],{{FN|a}} ihre Elemente/Komponenten sind einzelne [[Datei]]en.{{FN|a}}
* Die Bibliothek ist eine Datei,{{FN|a}} die darin enthaltenen Komponenten werden von den Programmen der Entwicklungsumgebung oder einer speziellen Bibliotheksverwaltungssoftware identifiziert und verarbeitet.
: Beispiele: Eine sogenannte [[Dynamic Link Library|'DLL']] bei Microsoft oder eine [[Partitioned Data Set|PO-Datei]] bei IBM-[[Großrechner]]n als Bibliothek für Quelltexte, Objektmodule oder ausführbare Lademodule.
* Unterschiedliche Arten von Bibliotheken werden in einer gemeinsamen Datei{{FN|a}} verwaltet, die Entwicklungsumgebung kann dies unterscheiden/verarbeiten. Beispiel: Eine 'MDB' bei [[Microsoft Access|MS Access]] enthält Bibliotheken mit Quellcode, Makros, vorübersetztem Pseudocode und anderen Codetypen.
* Es existiert keine ‚Bibliothek‘, die Komponenten werden als einzelne Dateien gespeichert und ausgeführt, z. B. als „EXE-Dateien“.
{{FNBox|
{{FNZ|a|verwaltet vom üblichen Dateiverwaltungssystem des Betriebssystems}}
}}

== Statische Bibliotheken ==
„Statische Bibliothek“ wird eine Programmbibliothek genannt, die [[Modul (Software)|Module]]/[[Unterprogramm]]e enthält, die durch einen so genannten [[Linker (Computerprogramm)|Linker]] (von englisch „to link“: verknüpfen) mit dem [[Compiler|Kompilat]] eines anderen Programms verbunden werden. Dabei erzeugt der Linker, in der Regel für ein Hauptprogramm, eine [[ausführbare Datei]] oder (je nach Betriebssystem) ein [[Lademodul]] in einer ''Ladebibliothek,'' in der die von diesem aufgerufenen Module fest (statisch) eingebunden/angehängt sind.

Ein optimierender Linker sucht aus den zugeordneten Objekt-Modulen (Bibliotheksdateien) nur jene Komponenten (Unterprogramme oder Daten) heraus, die vom Programm auch tatsächlich aufgerufen (referenziert) werden (und für die es im Programm keine [[Überschreiben (OOP)|überschreibende]] Implementierung gibt) und hängt sie dann an das Programm an. Die so entstehende Datei wird entsprechend größer. Einfache Linker fügen einfach das komplette Objekt-Modul bzw. die komplette Bibliothek hinzu und vergrößern das Programm dadurch noch mehr.

Eine statische Bibliothek ist im Allgemeinen selbst Ergebnis aus Quelltexten, aufgeteilt in mehrere Module, deren Kompilate ([[Objektcode|Objektmodule]]) dann vom Linker zu der Bibliothek zusammengefügt wurden.

Kommerzielle Anbieter von Frameworks, die den Quellcode ihrer Funktionen nicht offenlegen möchten, stellen diese den Entwicklern üblicherweise in Form von statischen Bibliotheken und den zugehörigen Header-Dateien bereit. Dadurch haben Software-Entwickler die Möglichkeit, die gebotenen Funktionen in ihren Programmen zu verwenden und in Binärform in ihre Programme einzubauen, ohne dass neben den Definitionen der Quellcode der Funktionen vorliegen muss.

Hardware-Hersteller, die ihre Schnittstellen nicht offenlegen möchten, bieten durch die Bereitstellung statischer Bibliotheken eine Möglichkeit, um Treiber für neue Betriebssystem-Kernel bereitzustellen, ohne selbst bei Updates tätig werden zu müssen. Damit ist es beispielsweise auf Linux-Systemen mit Hilfe vom [[Dynamic Kernel Module Support|DKMS]] möglich, Kernel-Module zu bauen, die die Anforderungen der gegebenen Kernel-Version erfüllen, ohne dass der komplette Quellcode vorliegen muss. Dies betrifft u. a. die Grafiktreiber von NVIDIA.

== Dynamische Bibliotheken ==
Aus ''dynamischen Bibliotheken'' werden Komponenten erst während der Laufzeit eines Programms über einen sogenannten [[Lader (Programmierung)|Lader]] in den [[Arbeitsspeicher]] geladen. Das geschieht entweder durch eine explizite Anweisung durch das Programm oder implizit durch einen so genannten ''Laufzeit-Lader'', wenn das Programm ''dynamisch gebunden'' wurde. Heutzutage geschieht dies meist mit Betriebssystem-Unterstützung, da (siehe unten) dynamische Bibliotheken gesondert behandelt werden bzgl. Swapping und Einblendung in den Programm-Adressraum. Der Lader ist somit heute meist zu weiten Teilen eine Betriebssystem-Komponente.

''Dynamisch gebundene'' Programme müssen sich um das Laden der benötigten dynamischen Komponenten nicht selbst kümmern. Beim ''dynamischen Binden'' werden Bibliothek und Kompilat nur lose verknüpft. Statt die notwendigen [[Debugsymbol|Symbole]] ([[Variable (Programmierung)|Variablen-]] und [[Label (Programmierung)|Sprungadressnamen]]) zu kopieren, wie beim [[Statisches Binden|statischen Binden]] der Fall, werden sie nur referenziert. Um das Laden der dynamischen Bibliotheken und Suchen der Symbole kümmert sich ein sogenannter ''Laufzeit-Binder''. Das Auflösen der referenzierten Symbole geschieht entweder sofort (noch vor Start des eigentlichen Programms bzw. beim Laden aus der Bibliothek) oder lazy (''faul)'', bei der ersten Verwendung des Symbols.

Ein typischer Anwendungsfall dafür, Bibliotheken ''explizit zu öffnen'' (die Adresse von Symbolen nach deren Namen zu suchen, um das Symbol zu verwenden), sind [[Plug-in]]-Architekturen. Ein weiteres Szenario ist eine optionale Bibliothek, die verwendet wird, falls vorhanden, deren Fehlen aber keinen Fehler darstellt.

Ein Vorteil von dynamischen Bibliotheken ist, dass Programme, die eine dynamische Bibliothek verwenden, von Fehlerbehebungen in der Bibliothek profitieren, ohne neu übersetzt werden zu müssen. Wird beispielsweise ein Fehler in der [[OpenSSL]]-Bibliothek gefunden und behoben (die entsprechende Bibliothek wurde ersetzt), so genügt ein Neustart der Programme, die diese Bibliothek verwenden, um den Fehler auch in diesen Programmen zu beheben.

Da die Dateien, in denen dynamische Bibliotheken gespeichert werden, bei der Benutzung nur gelesen und ausgeführt, aber nicht verändert werden, müssen [[Betriebssystem]]e mit [[Virtuelle Speicherverwaltung|virtuellem Speicher]] dynamische Bibliotheken nur einmal laden und können sie dann in den [[Adressraum]] aller verwendenden Prozesse einblenden. Dies ist beispielsweise bei [[Multitasking]]-Systemen vorteilhaft, wenn die Bibliotheken insgesamt sehr groß sind und von vielen Prozessen gleichzeitig verwendet werden. (Sollte die dynamische Bibliothek Zustände oder gespeicherte Daten besitzen, kann dies mit [[Copy-On-Write]] abgefangen werden.)

Viele moderne Betriebssysteme laden die dynamischen Bibliotheken jedoch nicht sofort, sondern blenden sie bei Bedarf direkt von der [[Festplattenlaufwerk|Festplatte]] aus ein – sie werden wie ''[[Paging#Seitenauslagerung|ausgelagerte]]'' [[Paging|Pages]] behandelt. Analog werden nicht benötigte Pages, die zu einer dynamischen Bibliothek gehören und nicht verändert wurden, einfach verworfen. Bei Bedarf können sie ja aus der Festplatte wieder geladen werden.

== Beispiele ==
Programmbibliotheken stellen Komponenten in bestimmten Zusammenhängen bereit, zu denen sie bezüglich ihrer Konstruktion und ihrer Schnittstellen passen (müssen). Dementsprechend gibt es Programmbibliotheken zum Beispiel in folgenden Zusammenhängen:
* Funktionen des [[Betriebssystem]]s
* Weitere System- und [[Dienstprogramm]]e
* Teilkomponenten von [[Integrierte Entwicklungsumgebung|Entwicklungsumgebungen]] und [[Programmiersprache]]n
* Komponenten von [[Standardsoftware]]-Produkten
* Komponenten von [[Individualsoftware]], die von den [[Anwender]]n in individuell festgelegten Bibliotheken verwaltet werden.
* [[GUI-Toolkit]]s zum Erstellen grafischer Benutzeroberflächen

== Bibliotheken in verschiedenen Programmiersprachen ==
Bibliotheken in Programmiersprachen enthalten Dienste, die nicht im Compiler implementiert sind, sondern in der Sprache selbst programmiert sind und mit dem Compiler zusammen oder völlig von ihm getrennt dem Programmierer zur Verfügung stehen. Im ersten Fall ist die Bibliothek meist in der Sprachbeschreibung festgelegt. Im zweiten Fall spricht man von einer externen Bibliothek.

In der Sprachbeschreibung festgelegte Bibliotheken unterscheiden sich teilweise stark im Umfang.
{| class="wikitable zebra sortable" style="text-align:right"
|-
! Sprache
! Teile/Pakete
! Header/Klassen
! Funktionen/Methoden/Konstruktoren
|-
|align="left"| C (C89+Amendments)
| 1
| 18
| 142
|-
|align="left"| C (C99)
| 1
| 24
| 482
|-
|align="left"| C++
| 1
| 32 + 18 (C89)
|
|-
|align="left"| Java 2 (JDK 1.2)
| 62
| 1.287
| ≈ 18.000
|-
|align="left"| Java 6
| 202
| 3.850
| 21.881
|-
|align="left"| [[.NET Framework|.Net]] 1.0
| 41
| 3.581
| 35.470
|-
|align="left"| .Net 1.1
| 43
| 3.818
| 37.556
|-
|align="left"| .Net 2.0
| 51
| 7.419
| 74.607
|-
|align="left"| .Net 3.0
| 80
| 10.639
| 102.613
|-
|align="left"| .Net 3.5
| 98
| 11.417
| 109.657
|}

=== Java ===
[[Java-Technologie|Java]] ist eine eigene [[Plattform (Computer)|Plattform]] und verwendet ein Bibliothekskonzept, welches nicht an das Betriebssystem gebunden ist. Im Grunde wird nicht zwischen Programm und Bibliothek unterschieden. Alle Klassen liegen kompiliert in Form von ''.class''-Dateien vor und werden bei Bedarf geladen. In der Regel sind Bibliotheken, wenn sie aus mehreren Klassen bestehen, in einem [[Java Archive|Java-Archiv]] zusammengefasst. Die Java-API selbst liegt ebenfalls in Form von Java-Archiven vor.

Da die einzelnen Klassen einer Bibliothek erst zur Laufzeit geladen werden, kann es bei der ersten Verwendung zu Verzögerungen kommen, bis die Klasse geladen und initialisiert wurde. In [[Real-Time Java|Java für Echtzeitsysteme]], aber auch in [[Java SE]] kann der Klassenlader durch entsprechende Methodenaufrufe bestimmte oder alle notwendigen Bibliotheken beim Starten laden und sie auch nicht mehr entladen, so dass bei der Benutzung keine unerwartete Verzögerung entsteht.

== Bibliotheken bei verschiedenen Betriebssystemen ==
=== Windows ===
Bei den [[Betriebssystem]]en [[Microsoft Windows|Windows]] und [[OS/2]] wird eine Bibliotheksdatei, die dynamisch bindet, als ''DLL'' (für [[Dynamic Link Library|'''''D'''ynamic '''L'''ink '''L'''ibrary'']]) bezeichnet. Entsprechend haben diese Dateien meist die [[Dateiendung]] '''.dll'''. Ihr Dateiformat ist [[New Executable]] (16 Bit), [[Linear Executable]] (32-Bit-OS/2) oder [[Portable Executable]] (32- bzw. 64-Bit-Windows).

Unter Windows wird zwischen mehreren Arten von DLLs unterschieden:
* Einsprungs-DLL
* [[ActiveX]]-DLL
* [[.NET Framework#Assemblies|.NET-Assembly]] ([[Common Language Infrastructure|CLI]])
* [[Windows Metadata]] ([[Common Language Infrastructure|CLI]], Dateiendung .winmd)
Einsprungs-DLLs enthalten hierbei Funktionen, während ActiveX-DLLs [[Klasse (Objektorientierung)|Klassen]] enthalten.

DLLs bis ''Windows 98'' und ''Windows NT 4.0'' können nicht kontrolliert werden – jedes Programm darf sie austauschen und kann dem Betriebssystem damit möglicherweise Schaden zufügen. ''Windows Me'', ''Windows 2000'' und die Folgeversionen verfügen über einen Systemschutz, der auch die DLLs einbezieht.

'''Vorteile'''
* Außer Code können auch Daten (zum Beispiel Dialog-Ressourcen) von mehreren Prozessen gemeinsam genutzt werden.
* DLLs werden häufig ''statisch verlinkt'', können aber auch ''dynamisch verlinkt'' werden. Dynamisch heißt hier, dass die DLL explizit vom Programm zur Laufzeit geladen wird und die Funktionen, die sich in der DLL befinden, „per Hand“ mit dem Programm verbunden werden. Dadurch wird es möglich, durch Austauschen der DLL die Funktionalität des Programms zur Laufzeit zu verändern.
* DLLs können unabhängig vom Hauptprogramm gewartet werden. Das heißt, Funktionen in der DLL können ohne Wissen des Programms verändert werden. Danach wird die DLL einfach ausgetauscht (die alte DLL-Datei wird überschrieben), ohne dass das Hauptprogramm verändert werden muss.
* Da die DLL als unabhängige Datei dem Hauptprogramm beiliegen muss, können Anbieter von Programmcode besser sicherstellen, dass Programmierer, die die Funktionen ihrer DLL nutzen, dafür auch bezahlen. Die Funktionalität der DLL verschwindet so nicht (wie bei einer Library) im Code des Programms. Dieser Vorteil wird von Befürwortern [[Freie Software|freier Software]] als Nachteil gesehen.

'''Nachteile'''
* Änderungen in DLLs ziehen oft auch Änderungen im Programm nach sich. Dadurch kommt es leicht zu Versionskonflikten, die oft nur sehr schwer aufzuspüren sind. Eine der Grundideen der DLLs war, Programmcode zwischen mehreren Programmen zu teilen, um so Speicher zu sparen. In der Praxis ist es jedoch dazu gekommen, dass viele Programme bei der Installation DLLs in das Windows-Systemverzeichnis schreiben, die außer diesem speziellen Programm kein anderes benutzen kann. Außerdem ist die Entwicklung und insbesondere die Anbindung im Vergleich aufwändiger als zur statischen Bibliothek.
* Praktisch hat dies jedoch keine Bedeutung mehr, da seit mindestens Windows 2000 die allermeisten Applikationen ''private Bibliotheken''<ref name="endofdllhell" /> mit ihrer Installation mitführen, also ein Versionskonflikt im Sinn eines [[DLL-Konflikt]]s ausgeschlossen ist. Unter Windows haben Bibliotheken, die im Programmordner der Anwendung abgelegt sind, eine höhere Priorität als die systemweit verfügbaren.<ref name="sharedlibpolicy">{{cite web|url=http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html|title=Using static and shared libraries across platforms; Row 9: Library Path|date=2011-07-20|archiveurl=https://web.archive.org/web/20110720003722/http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html|archivedate=2011-07-20|last=Desitter|first=Arnaud|publisher=ArnaudRecipes|accessdate=2012-01-26|quote=''win32 runtime library path:. and then PATH''|language=englisch}}</ref>

=== Unixartige Systeme ===
Auf [[Unixartiges Betriebssystem|unixartigen Betriebssystemen]] (wie z. B. [[Linux]]) verwenden statische Bibliotheken den Dateisuffix <code>.a</code> (von „Archiv“) und können mit den UNIX-Programmen <code>ar</code> und <code>nm</code> angesehen und bearbeitet werden. Bei Systemen, die eine Paketverwaltung anbieten, befinden sich statische Bibliotheken oft zusammen mit den [[Header-Datei]]en in einem separaten Entwicklungs-Paket.

Für dynamische Bibliotheken ist die Bezeichnung ''shared library'' (englisch für „gemeinsam genutzte Bibliothek“) gebräuchlich. Sehr verbreitet ist das [[Executable and Linking Format]] ''(ELF)'', das Standard-Format unter anderem von Linux, [[FreeBSD]] und [[Solaris (Betriebssystem)|Solaris]]. Für diese Dateien hat sich die Endung <code>.so</code> (von ''shared object'', „gemeinsam genutztes Objekt“) etabliert. In der Regel folgt dem Bibliotheksnamen noch die [[Versionsnummer]] der [[Binärschnittstelle]] ''(ABI version)'', so dass mehrere Versionen einer Bibliothek gleichzeitig installiert sein können. Meta-Informationen zu einem vorliegenden <code>.so</code> können bspw. mit <code>readelf</code> abgefragt werden.

''Shared libraries'' beginnen auf Linux (mit Ausnahme einiger Low-Level-Bibliotheken) üblicherweise mit dem [[Präfix]] „<code>lib</code>“. Die eigentliche Bibliotheksdatei enthält die volle Versionsnummer. [[Symbolische Verknüpfung]]en ermöglichen den Zugriff über den <code>so</code>-Namen, sowie den Zugriff ganz ohne Versionsangabe. Beispiel:
* <code>libfoo.so -> libfoo.so.1</code>
* <code>libfoo.so.1 -> libfoo.so.1.2.3</code>
* <code>libfoo.so.1.2.3</code>
Der <code>so</code>-Name ist in dem Fall „<code>libfoo.so.1</code>“. Die Zahl nach „<code>.so.</code>“ ändert sich nur dann, wenn sich in einer neuen Version die Schnittstelle der Bibliothek ändert.

Der Laufzeit-Linker wählt anhand von Versions-Informationen im auszuführenden Programm bzw. in der zu ladenden Bibliothek eine Version mit einer [[Binärkompatibilität|kompatiblen]] Schnittstelle aus. Da sowohl Programme von Bibliotheken abhängen können, als auch Bibliotheken von weiteren Bibliotheken, kann eine Software indirekt von vielen Bibliotheken abhängen. Da viele [[Unixoide Systeme]] die Bibliotheken zentral für Betriebssystem und Applikation zusammen verwalten, existieren [[Paketverwaltung]]en, die Abhängigkeiten berechnen und benötigte Bibliotheken automatisch installieren können. Beispiele für derartige Paketverwaltungs-Systeme sind [[Advanced Packaging Tool|APT]] und [[Yellowdog Updater, Modified|YUM]].

Von welchen Bibliotheken ein Programm direkt abhängt, lässt sich auf einigen Systemen mit Hilfe des UNIX-Programms <code>ldd</code> herausfinden.

Bei Software, die in der Binärversion vertrieben werden soll, beispielsweise kommerzielle [[Closed Source|Closed-Source-Software]] oder [[Portable Software|portable]]/distributionunabhängige Software, muss gewährleistet werden, dass alle benötigten Bibliotheken vorliegen. Das Anwendersystem, auf dem diese Software verwendet werden soll, muss dann als kompatible [[Plattform (Computer)|Binärplattform]] agieren können. Dies kann folgendermaßen geschehen:
* Angabe einer oder mehrerer kompatibler Betriebssystem-Distributionen, zum Beispiel: „Lauffähig unter Debian 5.0 (Lenny)“.
* Verwendung eines distributionsspezifischen Paketes, so dass benötigte Bibliotheken vom Paketmanager nachgeladen werden. Nachteil ist der enorme Aufwand der Bereitstellung eines Paketes für die vielen existierenden Distributionen.<ref name="linuxfordevices">{{cite web |last=Brown |first=Eric |title=LSB 4.0 certifications aim to heal Linux fragmentation |language=englisch |date=2010-12-08 |publisher=linuxfordevices.com |url=http://archive.linuxgizmos.com/lsb-40-certifications-aim-to-heal-linux-fragmentation/ |archiveurl=https://web.archive.org/web/20131224204224/http://archive.linuxgizmos.com/lsb-40-certifications-aim-to-heal-linux-fragmentation/ |archivedate=2013-12-24 |offline=yes |accessdate=2011-11-16 |archivebot= |quote=''[…] LSB helps to reduce fragmentation, it does not eliminate it. „The issue of packaging and broader dependencies is still a big one (for me) at least,“ writes Kerner. „The same RPM that I get for Fedora won’t work on Ubuntu, and Ubuntu DEB packages won’t work on SUSE etc etc.“[…]''}}</ref><ref name="lgp2">{{cite web|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/|title=Playing well with distros|date=2009-11-24|accessdate=2012-01-15 |first=Eskild|last=Hustvedt|publisher=[[Linux Game Publishing]]|language=englisch|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/|archivedate=2011-09-21}}</ref>
* Mitliefern aller dynamischen Bibliotheken. Diese werden, zusammen mit dem Programm, Dokumentation usw. in ein separates Verzeichnis kopiert, um nicht mit Versionen, die von der Paketverwaltung systemweit installiert wurden, zu kollidieren. Anschließendes Anpassen des Bibliothekensuchpfads für das Programm mit <code>LD_LIBRARY_PATH</code> über ein Skript oder händisch.<ref name="lgp" />
* Verzicht auf dynamische Bibliotheken und ''[[Statisches Linken]]'', was aber technisch schwierig ist<ref name="jones">{{cite web|url=https://www.evanjones.ca/portable-linux-binaries.html|title=Portable Linux Binaries |date=2008-02-13 |accessdate=2012-01-10|language=englisch |first=Evan |last=Jones|quote=''Linux is not well known for its binary portability. Libraries vary from system to system, and the kernel interfaces have a tendency to change. […] Recently, I needed to build a binary on one system, and run it on another. It only used standard C library functions, so I expected it to be easy. It was not. […]''}}</ref><ref name="baus">{{cite web|url=http://www.baus.net/statically-linking-libstdc++|archiveurl=https://web.archive.org/web/20100210063024/http://www.baus.net/statically-linking-libstdc++|archivedate=2010-02-10 |date=2005-05-31 |title=Yet another Unix nightmare: statically linking libstdc++ |first=Christoph |last=Baus|language=englisch| accessdate=2012-01-15}}</ref> oder durch Lizenzkonflikte verhindert werden kann. Außerdem verliert man damit Distribution-basierenden Updatesupport.<ref name="drepper">{{cite web|url=http://people.redhat.com/drepper/no_static_linking.html|archiveurl=https://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html|archivedate=2010-05-27|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=[[Red Hat Linux|redhat.com]]|language=englisch|accessdate=2012-01-13}}</ref>
* Über ''private Bibliotheken''<ref name="endofdllhell">{{cite web
| url=http://msdn.microsoft.com/library/techart/dlldanger1.htm
| title=The End of DLL Hell
| date=2000-01-11
| archiveurl=https://web.archive.org/web/20010605023737/http://msdn.microsoft.com/library/techart/dlldanger1.htm
| archivedate=2001-06-05
| last=Anderson
| first=Rick
| publisher=microsoft.com
| accessdate=2012-01-15
| quote=''Private DLLs are DLLs that are installed with a specific application and used only by that application.''
}}</ref> die über einen relativen Bibliothekspfad eingebunden werden. Hierzu muss die Applikation mit der [[Linker (Computerprogramm)|Linker]]-Option <code>$ORIGIN</code> erzeugt werden.<ref name="lgp">{{cite web|url=http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/ |title=Our new way to meet the LGPL|date=2009-02-08 |accessdate=2011-03-09 |first=Eskild |last=Hustvedt |quote=''You can use a special keyword $ORIGIN to say ‘relative to the actual location of the executable’. Suddenly we found we could use -rpath $ORIGIN/lib and it worked. The game was loading the correct libraries, and so was stable and portable, but was also now completely in the spirit of the LGPL as well as the letter!'' |language=englisch |archiveurl=https://web.archive.org/web/20140413195014/http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/ |archivedate=2014-04-13}}</ref>

Objekt- und komponentenorientierte Ansätze können hier realisiert werden, indem in einer Funktion das entsprechende Objekt oder die Komponente instantiiert und zurückgegeben werden.

'''Vorteile'''
* Gemeinsame Nutzung von Ressourcen
* Vermeidung von redundanten privaten Libraries
* Eine enorme Anzahl von freien und mitgelieferten Bibliotheken stehen zur Verfügung
* Bibliotheken können unabhängig vom Hauptprogramm ausgebessert werden<ref name="drepper" /> und Programmupdates werden kleiner
* Optimierungen an einer Stelle können das ganze System beschleunigen
* Können schnell veränderliche [[Systemaufruf]]e verbergen
* Abstrahieren von low-level Problemen

'''Nachteile'''
* Probleme in essentiellen Bibliotheken machen Systeme unbenutzbar. Durch entsprechende Skripte der Paketverwaltung ist bei modernen Distributionen jedoch meist sichergestellt, dass dies nicht passieren kann.
* Bei inkompatiblen Veränderungen der [[Binärschnittstelle]] müssen alle abhängigen Programme neu kompiliert werden. Durch Versionsnummern und parallele Verwendung von Paketen reduziert sich das Problem der Binärkompatibilität, wird jedoch nicht gelöst.<ref name="binaryproblems">{{cite web|url=http://trac.autopackage.org/wiki/LinuxProblems|title=Random Collection of Current Linux Problems Binary Portability|quote=''This page was prepared for the OSDL meeting in December 2005. It describes many of the problems inherent to Linux we’ve encountered whilst distributing complex software in binary form to end users. It also offers a few suggestions for improvements.'' |publisher=[[Autopackage]].org |date=2006 |accessdate=2012-01-23 |archiveurl=https://web.archive.org/web/20090518100250/http://trac.autopackage.org/wiki/LinuxProblems |archivedate=2009-05-18 |language=englisch |first=Mike|last=Hearn}}</ref>
* Bei inkompatiblen Veränderungen der [[Programmierschnittstelle]] müssen alle abhängigen Programme entsprechend angepasst werden.
* Die Erstellung [[Portable Software|portabler]] oder distributionsübergreifender Programme wird schwieriger.<ref name="troy">{{cite web|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp |title=Linux Game Development Part 2 – Distributable Binaries|first=Troy |last=Hepfner |date=2007-10-01 |accessdate=2011-12-19 |archivedate=2007-10-13 |language=englisch |quote=''Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]''|publisher=gamedev.net}}</ref><ref name="portableapps">{{cite web |last=Peter |first=Simon |title=AppImageKit Documentation 1.0 |language=englisch |date=2010 |publisher=PortableLinuxApps.org |url=http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archiveurl=https://web.archive.org/web/20101129031656/http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archivedate=2010-11-29 |offline=yes |format=PDF; 38 kB |accessdate=2011-07-29 |archivebot= |pages=2–3 |quote=''Not easy to move an app from one machine to another''}}</ref>

=== Bibliotheken unter z/OS ===
Bei ''[[z/OS]]'' wie auch in den Vorgängersystemen [[System/360]] und [[System/390]] werden/wurden Programmbibliotheken (wie alle Arten von Bibliotheken) in der Form von [[Partitioned Data Set]]s (PDS) geführt. Je Programmcode-Typ (siehe unten) werden i. d. R. eigene Bibliotheken benutzt und deren Elemente typneutral als ''Member'' bezeichnet. Die Members werden von verschiedenen Systemprogrammen der Entwicklungsumgebung dort eingestellt und von dort verwendet.

Je Programmcode-Typ wird – je nach Bedarf – eine (1) Bibliothek für ein ganzes Unternehmen, je Unternehmensbereich oder für bestimmte Anwendungsgebiete verwendet. Die Unterscheidung der Einträge erfolgt über den Membernamen. Es werden zum Beispiel folgende Arten von Programmbibliotheken benutzt:
[[Datei:Compilerszenario Großrechner.png|mini|Code-/Bibliothekstypen z. B. bei z/OS (mit 3GL-Sprache)]]
* ''Quelltextbibliotheken:'' Diese enthalten den [[Quellcode]] von Programmen oder Unterprogrammen, d. h. [[Deklaration (Programmierung)|Deklarationen]], [[Funktion (Programmierung)|Funktionen]] und je nach Programmiersprache andere Codeteile. Besondere Ausprägungen von Quelltexten werden oft in getrennten Bibliotheken verwaltet; Beispiele sind:
** ''[[Copybook]]-Bibliotheken;'' sie enthalten Fragmente von Quellcode, zum Beispiel Datendeklarationen für bestimmte [[Datensatz]]-Arten oder funktionale Codeteile zur Verwendung in vielen Programmen.
** ''Makrobibliotheken'' enthalten zum Beispiel für die Assemblersprache die Anweisungen, durch die beim Assemblieren der Makroaufruf in ASSemblercode umgewandelt und im Quellcode eingefügt wird.
: Die Einträge in Quelltextbibliotheken werden üblicherweise mithilfe von Texteditoren erzeugt und geändert sowie von Compilern/Assemblern als Input benutzt, um kompilierten Programmcode zu erzeugen.
* In ''Objektcode-Bibliotheken'' werden von den Übersetzern [[Objektcode|Objektmodule]] eingestellt, je Kompilierung in der Regel ein Modul. Diese Module sind der Input für das anschließend erforderliche Linken oder Binden; dem auch [[Linker (Computerprogramm)|Linkage Editor]] genannten Systemprogramm wird diese Bibliothek als SYSLIB bekanntgegeben.
* Beim Binden entstehen sogenannte [[Lademodul]]e, die in einer ''Ladebibliothek'', u. a. auch „Core Image Library“ genannt, eingestellt werden. Ladebibliotheken können
** unternehmensweit in nur einer gemeinsamen Bibliothek alle Programm-Typen enthalten oder
** wahlweise (und in der Regel) in getrennten Bibliotheken die (per [[Job Control Language|JCL]]) aufzurufenden ''Hauptprogramme'' bzw. die per Load-Befehl individuell nachzuladenen ''Unterprogramme'' aufnehmen.
: Zur [[Ausführbare Datei|Ausführung]] werden evtl. unterschiedliche Bibliotheken über die STEPLIB- oder die JOBLIB- oder die LINKLIST-Angabe zugeordnet und die einzelnen Module daraus vom [[Betriebssystem]] geladen.

=== Bibliotheken unter Amiga OS ===
Beim [[AmigaOS]] werden alle Bibliotheken als shared Library verwendet. Sie werden also zur Laufzeit vom Programm beim System angefordert, das dann die Basisadresse der Bibliothek im Speicher (bis OS 3.9) oder die entsprechende Schnittstelle (ab OS 4.0) zur Verfügung stellt. Das Programm verwendet dann relative Adressen, um über eine [[Sprungtabelle]] vor der Basisadresse an die eigentlichen Funktionen (hinter der Basisadresse) zu kommen. Diese Funktionen sind [[Eintrittsinvarianz|eintrittsinvariant]] (reentrant).

Selbst bei Änderungen der Bibliothek sind die bestehenden Einträge der Sprungtabellen immer gleich. Es kommen ggf. lediglich neue Einträge hinzu am Ende der Tabellen. Somit ist eine [[Abwärtskompatibilität]] gegeben.

Als Besonderheit kann bei AmigaOS beim Öffnen einer Library eine Mindest-Versionsnummer angegeben und so sichergestellt werden, dass eine gewünschte Funktionalität auch wirklich verfügbar ist. Wird diese Version nicht vorgefunden, kann das aufrufende Programm sicher auf eine einfachere Funktionalität, wie sie in der älteren Library-Version bereitgestellt wird, zurückschalten.

Bibliotheksdateien tragen die Endung '''.library''' und befinden sich meist im Verzeichnis '''LIBS:''' der [[Systempartition]]. Das Betriebssystem überprüft bei der Suche nach einer Bibliothek auch das Programmverzeichnis des anfragenden Programms.

== Weblinks ==
{{Wiktionary}}
* Mike Hearn: [https://plan99.net/~mike/writing-shared-libraries.html Writing shared libraries] – Fallstricke und [[Best Practice]]s der Erstellung von ELF-Bibliotheken, 2004 (englisch)

== Einzelnachweise ==
<references />

{{Normdaten|TYP=s|GND=4121521-7|LCCN=|NDL=|VIAF=}}

[[Kategorie:Programmbibliothek| ]]

Programmbibliothek - Versionsgeschichte

imported>BrunoBoehmler: /* Bibliotheken unter Amiga OS */ fehlende Leerzeichen ergänzt