“三下乡”让西丰 群众家门口享福利
Eine Programmbibliothek (kurz Bibliothek; englisch library, kurz lib) bezeichnet in der Programmierung eine Sammlung von Unterprogrammen/-routinen, die L?sungswege für thematisch zusammengeh?rende Problemstellungen anbieten. Bibliotheken sind im Unterschied zu Programmen keine eigenst?ndig lauff?higen Einheiten, sondern sie enthalten 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 Entwicklungsumgebung), andere nur zur Ausführung von Programmen, wieder andere als Mischform von beiden. Solche Bibliotheken enthalten h?ufig nicht nur Unterprogramme, sondern Programmcodeteile aller Programm-Typen.
Eine besondere Form von Programmbibliotheken sind Frameworks.
Zugriff
[Bearbeiten | Quelltext bearbeiten]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?ren Programmbibliotheken werden nicht im Quelltext ver?ffentlicht, da sie Firmengeheimnisse darstellen. Zum Schutz gegen Dekompilieren wird dann oft ein Obfuscator eingesetzt sowie alle Symbole (Variablen- und Sprungadressnamen) entfernt.
Speicherungsformen
[Bearbeiten | Quelltext bearbeiten]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 Dateiverzeichnis, a ihre Elemente/Komponenten sind einzelne Dateien. a
- Die Bibliothek ist eine Datei, a die darin enthaltenen Komponenten werden von den Programmen der Entwicklungsumgebung oder einer speziellen Bibliotheksverwaltungssoftware identifiziert und verarbeitet.
- Beispiele: Eine sogenannte 'DLL' bei Microsoft oder eine PO-Datei bei IBM-Gro?rechnern als Bibliothek für Quelltexte, Objektmodule oder ausführbare Lademodule.
- Unterschiedliche Arten von Bibliotheken werden in einer gemeinsamen Datei a verwaltet, die Entwicklungsumgebung kann dies unterscheiden/verarbeiten. Beispiel: Eine 'MDB' bei 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“.
Statische Bibliotheken
[Bearbeiten | Quelltext bearbeiten]?Statische Bibliothek“ wird eine Programmbibliothek genannt, die Module/Unterprogramme enth?lt, die durch einen so genannten Linker (von englisch ?to link“: verknüpfen) mit dem 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 ü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 (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 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
[Bearbeiten | Quelltext bearbeiten]Aus dynamischen Bibliotheken werden Komponenten erst w?hrend der Laufzeit eines Programms über einen sogenannten 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 Symbole (Variablen- und Sprungadressnamen) zu kopieren, wie beim 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 Betriebssysteme mit 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 Festplatte aus ein – sie werden wie ausgelagerte 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
[Bearbeiten | Quelltext bearbeiten]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 Betriebssystems
- Weitere System- und Dienstprogramme
- Teilkomponenten von Entwicklungsumgebungen und Programmiersprachen
- Komponenten von Standardsoftware-Produkten
- Komponenten von Individualsoftware, die von den Anwendern in individuell festgelegten Bibliotheken verwaltet werden.
- GUI-Toolkits zum Erstellen grafischer Benutzeroberfl?chen
Bibliotheken in verschiedenen Programmiersprachen
[Bearbeiten | Quelltext bearbeiten]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.
| Sprache | Teile/Pakete | Header/Klassen | Funktionen/Methoden/Konstruktoren |
|---|---|---|---|
| C (C89+Amendments) | 1 | 18 | 142 |
| C (C99) | 1 | 24 | 482 |
| C++ | 1 | 32 + 18 (C89) | |
| Java 2 (JDK 1.2) | 62 | 1.287 | ≈ 18.000 |
| Java 6 | 202 | 3.850 | 21.881 |
| .Net 1.0 | 41 | 3.581 | 35.470 |
| .Net 1.1 | 43 | 3.818 | 37.556 |
| .Net 2.0 | 51 | 7.419 | 74.607 |
| .Net 3.0 | 80 | 10.639 | 102.613 |
| .Net 3.5 | 98 | 11.417 | 109.657 |
Java
[Bearbeiten | Quelltext bearbeiten]Java ist eine eigene 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-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 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
[Bearbeiten | Quelltext bearbeiten]Windows
[Bearbeiten | Quelltext bearbeiten]Bei den Betriebssystemen Windows und OS/2 wird eine Bibliotheksdatei, die dynamisch bindet, als DLL (für Dynamic Link Library) 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-Assembly (CLI)
- Windows Metadata (CLI, Dateiendung .winmd)
Einsprungs-DLLs enthalten hierbei Funktionen, w?hrend ActiveX-DLLs 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 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[1] mit ihrer Installation mitführen, also ein Versionskonflikt im Sinn eines DLL-Konflikts ausgeschlossen ist. Unter Windows haben Bibliotheken, die im Programmordner der Anwendung abgelegt sind, eine h?here Priorit?t als die systemweit verfügbaren.[2]
Unixartige Systeme
[Bearbeiten | Quelltext bearbeiten]Auf unixartigen Betriebssystemen (wie z. B. Linux) verwenden statische Bibliotheken den Dateisuffix .a (von ?Archiv“) und k?nnen mit den UNIX-Programmen ar und nm angesehen und bearbeitet werden. Bei Systemen, die eine Paketverwaltung anbieten, befinden sich statische Bibliotheken oft zusammen mit den Header-Dateien 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. Für diese Dateien hat sich die Endung .so (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 .so k?nnen bspw. mit readelf abgefragt werden.
Shared libraries beginnen auf Linux (mit Ausnahme einiger Low-Level-Bibliotheken) üblicherweise mit dem Pr?fix ?lib“. Die eigentliche Bibliotheksdatei enth?lt die volle Versionsnummer. Symbolische Verknüpfungen erm?glichen den Zugriff über den so-Namen, sowie den Zugriff ganz ohne Versionsangabe. Beispiel:
libfoo.so -> libfoo.so.1libfoo.so.1 -> libfoo.so.1.2.3libfoo.so.1.2.3
Der so-Name ist in dem Fall ?libfoo.so.1“. Die Zahl nach ?.so.“ ?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 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 Paketverwaltungen, die Abh?ngigkeiten berechnen und ben?tigte Bibliotheken automatisch installieren k?nnen. Beispiele für derartige Paketverwaltungs-Systeme sind APT und YUM.
Von welchen Bibliotheken ein Programm direkt abh?ngt, l?sst sich auf einigen Systemen mit Hilfe des UNIX-Programms ldd herausfinden.
Bei Software, die in der Bin?rversion vertrieben werden soll, beispielsweise kommerzielle Closed-Source-Software oder 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 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.[3][4]
- 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
LD_LIBRARY_PATHüber ein Skript oder h?ndisch.[5] - Verzicht auf dynamische Bibliotheken und Statisches Linken, was aber technisch schwierig ist[6][7] oder durch Lizenzkonflikte verhindert werden kann. Au?erdem verliert man damit Distribution-basierenden Updatesupport.[8]
- über private Bibliotheken[1] die über einen relativen Bibliothekspfad eingebunden werden. Hierzu muss die Applikation mit der Linker-Option
$ORIGINerzeugt werden.[5]
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[8] und Programmupdates werden kleiner
- Optimierungen an einer Stelle k?nnen das ganze System beschleunigen
- K?nnen schnell ver?nderliche Systemaufrufe 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.[9]
- Bei inkompatiblen Ver?nderungen der Programmierschnittstelle müssen alle abh?ngigen Programme entsprechend angepasst werden.
- Die Erstellung portabler oder distributionsübergreifender Programme wird schwieriger.[10][11]
Bibliotheken unter z/OS
[Bearbeiten | Quelltext bearbeiten]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 Sets (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:
- Quelltextbibliotheken: Diese enthalten den Quellcode von Programmen oder Unterprogrammen, d. h. Deklarationen, 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 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 Linkage Editor genannten Systemprogramm wird diese Bibliothek als SYSLIB bekanntgegeben.
- Beim Binden entstehen sogenannte Lademodule, 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 JCL) aufzurufenden Hauptprogramme bzw. die per Load-Befehl individuell nachzuladenen Unterprogramme aufnehmen.
- Zur 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
[Bearbeiten | Quelltext bearbeiten]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 OS3.9) oder die entsprechende Schnittstelle (ab OS4.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 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
[Bearbeiten | Quelltext bearbeiten]
- Mike Hearn: Writing shared libraries Fallstricke und Best Practices der Erstellung von ELF-Bibliotheken, 2004 (englisch)
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b Rick Anderson: The End of DLL Hell. microsoft.com, 11. Januar 2000, archiviert vom am 5. Juni 2001; abgerufen am 15. Januar 2012: ?Private DLLs are DLLs that are installed with a specific application and used only by that application.“
- ↑ Eric Brown: LSB 4.0 certifications aim to heal Linux fragmentation. linuxfordevices.com, 8. Dezember 2010, archiviert vom am 24. Dezember 2013; abgerufen am 16. November 2011 (englisch): ?[…] 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.“[…]“
- ↑ Eskild Hustvedt: Playing well with distros. Linux Game Publishing, 24. November 2009, archiviert vom am 21. September 2011; abgerufen am 15. Januar 2012 (englisch).
- ↑ a b Eskild Hustvedt: Our new way to meet the LGPL. 8. Februar 2009, archiviert vom am 13. April 2014; abgerufen am 9. M?rz 2011 (englisch): ?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!“
- ↑ Evan Jones: Portable Linux Binaries. 13. Februar 2008, abgerufen am 10. Januar 2012 (englisch): ?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. […]“
- ↑ Christoph Baus: Yet another Unix nightmare: statically linking libstdc++. 31. Mai 2005, archiviert vom am 10. Februar 2010; abgerufen am 15. Januar 2012 (englisch).
- ↑ a b Ulrich Drepper: Static Linking Considered Harmful. redhat.com, archiviert vom am 27. Mai 2010; 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. […]“
- ↑ Mike Hearn: Random Collection of Current Linux Problems Binary Portability. Autopackage.org, 2006, archiviert vom am 18. Mai 2009; abgerufen am 23. Januar 2012 (englisch): ?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.“
- ↑ Troy Hepfner: Linux Game Development Part 2 – Distributable Binaries. gamedev.net, 1. Oktober 2007, archiviert vom am 13. Oktober 2007; abgerufen am 19. Dezember 2011 (englisch): ?Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]“
- ↑ Simon Peter: AppImageKit Documentation 1.0. (PDF; 38 kB) PortableLinuxApps.org, 2010, S. 2–3, archiviert vom am 29. November 2010; abgerufen am 29. Juli 2011 (englisch): ?Not easy to move an app from one machine to another“