Wichtige Entwicklungswerkzeuge

Die meisten Kommandozeilenangaben des GNU-Compilers gcc entsprechen denen anderer C-Compilier unter Linux/Unix, jedoch gibt es auch einige gcc-spezifische Angaben und Eigenheiten. Hier werden die wichtigsten Kommandozeilenangaben und Eigenschaften des gcc-Compiliert kurz vorgestellt. Fuer weitergehende Informationen sollte man die Manpage von gcc aufrufen.

gcc ist das Kommando zum Aufruf des GNU-C-Compilers. Es erzeugt ausfuehrbare Programme, indem es die angegebenen Datei(en) kompiliert. bzw. assembliert, bevor es den Linker ld aufruft, um die entsprechenden Objectdateien zu einem ausfuehrbaren Programm zusammenbinden zu lasen. Die Voreinstellung ist, dass gcc das erzeugte Programm in einer Datei mit dem Namen a.out ablegt. Als Datei(en) akzeptiert gcc eine ganze Reihe von Dateitypen, die gcc dabei ueber das Suffix klassifiziert Die wichtigsten Suffixe sind folgende:

Jetzt folgt eine Auflistung wichtiger Optionen, die beim Arbeiten mit gcc haeufig benoetigt werden

gcc bietet einige Konstrukte an, die nicht von ANSI C vorgeschrieben sind. Nachfolgend sind einige wichtige solcher Konstrukte beschrieben.

gcc bietet eine Reihe von zusaetzlichen Schluesselwoertern an, die nicht von ANSI C vorgeschrieben sind. Solche zusaetzlichen Schluesselwoerter werden von gcc in zwei Varianten angeboten: einmal das Schluesselwort selbst (wie z. B. attribute) und zum anderen das Schluesselwort mit zwei vorangestellen und zwei angefuegten Unterstricken (wie z. B. __attribute__). Wird gcc mit der Option -ansi aufgerufen, kann er die zusaetzlichen normalen Schluesselwoerter nicht erkennen. Deshalb wurde zu jedem zusaetzlichen Schluesselwort alternativ in den Headerdateien ein entsprechender Datentyp mit zwei vorangestellen und zwei angefuegten Unterstrichen angeboten.
Das zusaetzliche Schluesselwort attribut ermoeglicht es, gcc mehr Informationen ueber eine Funktion, Variable oder einen Datentyp zu geben, als dies mit den Standardkonstrukten von ANSI C moeglich ist. Nachfolgend sind einige moegliche Attribute aufgefuehrt:

Attribute fuer Funktionen muessen der Funktionsdeklaration hinzugefuegt werden, wie z. B.:

Das Schluesselwort \\Schluesselwort attribut ist nach den Funktionsparametern, gefolgt von dem zu setzendem Attribut, das sich in doppelten Klammernpaaren befindet, anzugeben. Sollen mehrere Attribute gesetzt werden, muessen diese mit Kommata getrennt werden, wie z. B.:

Diese Deklaration legt fest, dass ext3_panic nicht zur aufrufenden Funktion zurueckkehrt und das die uebergebenen Argumente (ab dem dritten) wie bei der Funktion printf zu behandeln sind: Das dritte Argumente legt den Formatierungsstring fest und das vierte Argument ist der erste zu ersetzende Parameter im Formatierungsstring. Spaeter werden weitere Attribute (z. B. beim Erzeugen von dynamischen Bibliotheken) vorgestellt. Alle moeglichen Attribute stehen in der Manpage von gcc.

ld ist der Linux/Unix-Linker, der mehrere Objectdateien zu einem ausfuehrbaren Programm zusammenbindet. Objectdateien erkenn ld am Suffix .o. Archivbibliotheken, in denen der Linker nach unresolved references suchen soll, erkennt er am Suffix .a. Fal einer der angegebenen Dateien weder das .o-, noch das .a-Suffix hat, so nimmt ld an, dass es sich um eine Archivbibliothek oder um eine Textdatei, die Link-Editordirektiven enthaelt, handelt. Die Voreinstellung ist, dass ld das erzeugte Programm in einer Datei mit dem Namen a.out ablegt, wenn keine Fehler aufgetreten sind; ansonsten bricht ld mit einer Fehlermeldung ab. Explizit auf der Kommandozeile angegebene Bibliotheken werden nur nach unresolved references durchsucht, die aus zuvor angegebenen Objectdateien resultieren. Allgemein gilt, dass man alle Objectdateien vor den Bibliotheken auf der Kommandozeile angeben sollte.

Da ld auf den einzelnen Systemen auch die unterschiedlichsten Optionen anbietet, werde ich hier nur die wichtigsten Optionen vorstellen, die auch auf den meisten Systemen gueltig sind. Um spezielle fuer ein System angebotetnen Optionen zu erfahren, sollte man die Manpage von ld oder die mitgelieferten Dokumentationen durchlesen.

Da ld automatisch von cc bzw. gcc aufgerufen wird, nachdem cc bzw. gcc alle C- und Assemblerprogramme assembliert bzw. kompiliert hast, wird meist cc bzw. gcc zur Erzeugung eines ausfuehrbaren Programms verwendet.

db ist der uebliche Debugger unter Linux/Unix. Hier wird der GNU-gbd von der Free Software Foundation beschrieben, dessen Bedienung weitgehend der entspricht, wie sie auch fuer die unter anderen Unix-Systemen angebotenen Debuggern des gleichen Namens gilt. Der hier beschriebene gdb ist ein kommandozeilenorientierter Debugger, zu dem es inzwischen mehrere graphische Debugger angeboten werden, wie z. B.:

Um sich einen ersten Ueberblick ueber die von gdb angebotenen Kommandos zu verschaffen, empfiehlt es sich, gdb zu starten und dann das gdb-Kommando help aufzurufen.

In diesem Beispiel kann man unter anderem sehen, dass man sich detailliertere Informationen zu den einzelnen gdb-Kommandos anzeigen lassen kann, indem man help commando eingibt. Wie oben gezeigt ist es auch moeglich, gdb ohne Angabe von Argumenten zu starten, aber ueblicherweise ruft man den gdb jedoch mit einem Argument, dem Namen des zu debuggenden Programms, auf. Dazu uebergibt man gdb den Namen einfach als Argument: gdb programm. Zusaetzlich zum Namen des zu debuggenden Programms kann auch eine core-Datei angegeben werden, die bei einem vorherigen Start des Programms vom System generiert wurde. Der Programmaufruf waere hier gdb programm core-file. Der gdb bietet auch die Moeglichkeit, ein gerade laufendes Programm zu debuggen. Dazu muss der gdb sich mit diesem laufenden Prozess verbinden koennen, was man durch gdb programm PID erreicht.
Im gdb ist es nicht notwendig, die entsprechenden gdb-Kommandos vollstaendig auszuschreiben, sondern diese koennen auch abgekuerzt werden. So kann z. B. statt dem Kommando running nur run oder r verwendet werden. Um das letzte Kommando zu wiederhole, muss man lediglich die Return-Taste druecken, was das schrittweise Debuggen eines Programms erheblich erleichtert. Einige gdb-Kommandos koennen auch mit Formatangaben aufgerufen werden, um das Ausgabeformat von Werten festzulegen. Solche Formatangaben muessen mit / beginnend unmittelbar nach dem entsprechenden gdb-Kommando angegeben werden. Formatangaben bestehen aus vier Komponenten: /zfg, die im einzelnen folgende Bedeutung haben:

Hat man einmal fuer ein gdb-Kommando eine Formatangabe festgelegt, muss man diese bei einem erneuten Aufruf des Kommandos nicht wieder eingeben, da gdb dann immer die zuletzt definierte Formatangabe wiederverwendet. Nachfolgend sind die am haeufigsten benutzten gdb-Kommandos kurz aufgelistet:

Bei der Fehlersuche in Programmen kann das Kommando strace , das jeden Aufruf einer Systemfunktion mitprotokolliert, wertvolle Dienste leisten. Moechte man sich z. B. alle Aufrufe von Systemfunktionen beim Ablauf des Kommandos date anzeigen lassen, muss man nur strace date aufrufen.

strace verfolgt den Ablauf des Kommandos command mit und gibt alle Systemaufrufe und Signale auf die Standardfehlerausgabe oder - wenn die Option -o file angegeben ist - in die Datei file Jede Zeile der Ausgabe enthaelt einen Systemaufruf, seine Argumente in Klammern und den Rueckgabewert, wie z. B.:

Bei einem Fehler (meist der Rueckgabewert -1) wird die Fehlernummer (als symbolischer Name) und die zugehoerige Fehlermeldung mitausgegeben, wie z. B.:

Neuere Versionen von strace rufen stat64 bzw. lstat64, anstelle von open auf:

bzw.

Nachfolgend eine kurze Beschreibung zu einigen Optionen von strace

Das Kommando ar ermoeglicht es, mehrere Dateien in einer sogenannten statischen Archivbibliothek unterzubringen. Ebenso koennen mit ar neue Dateien in einer bereits erstellen Archivbibliothek aufgenommen bzw. aus ihr extrahiert oder entfernt werden. Die Aufrufesyntax ist ar [-V] [-]schluessel [posname] archiv_datei [datei(en)]. Eine statische Archivbibliothek enthaelt am Anfang eine sogenannte Symboltabelle, die Informationen ueber die in der Bibliothek enthaltenen Dateien bereitstellt, um einen moeglichst effizienten Zugriff auf die jeweiligen Dateien durch die entsprechenden Tools zu ermoeglichen, wie z. B. dem Linker ld, dem man wohl eine Bibliothek von Objectdateien auf der Kommandozeile uebergibt. Eine Symboltabelle wird nur dann von ar erstellt, wenn sich wenigstens eine Datei in der Bibliothek befindet. Die Angaben auf der Kommandozeile bedeuten im einzelnen:

Wenn bei datei(en) dieselbe Datei zweimal angegeben ist kann sich auch zweimal im Archiv aufgenommen werden. Archivdateien sollten immer das Suffix .a haben. Das Kommando ar bewirkt keine nennenswerte Speicherplatzeinsparungen, da die angegebenen Dateien nicht komprimiert werden. Manche Unix-Systeme fordern, dass die Symboltabelle einer Archivdatei eventuell zuerst mit ranlib archiv bzw. ar s archiv ktualisiert werden muss, bevor sie von ld bearbeitet werden kann. Zur Erstellung und Pflege von Archiven koennen auch die beiden Kommandos tar und cpio verwendet werden. Es ist aber wichtig zu wissen, dass alle drei Kommandos verschiedene Archivformate benutzen und somit ein einmal erstelltes Archiv auch nur wieder mit dem gleichen Kommando bearbeitet werden kann.

Das Kommando ar wird verwendet, um eine Archivbibliothek von kompilierten C-Funktionen anzulegen, die dem Linker ld zum Einbinden der benoetigten Funktionen vorgelegt wird. ld wird zwar automatisch von cc bzw. gcc aufgerufen, kann jedoch auch direkt aufgerufen werden. ar kann auch verwendet werden, um miteinander verwandte Textdateien (wie z. B. C-Quellprogramme oder Briefe) in einem Archiv unterzubringen. Dies fuehrt zu einer erheblichen Reduzierung der Dateien in einem Directory und dient somit auch der Uebersichtlichkeit. ar wird haeufig auch verwendet, wenn eine grosse Zahl von Dateien kopiert werden muss. In diesem Fall werden alle zu kopierenden Dateien zunaechst in einem Archiv abgelegt, bevor das gesamte Archiv kopiert wird.

In Zeile 1 ist zu sehen, dass im $PWD die Dateien five.o, four.o, libOne.a, one.o, three.o, two.o vorhanden sind und in Zeile 2 der Inhalt der Archivbibliothek libOne.a angezeigt (das Ergebnis steht in Zeile 4). In Zeile 5 werden die Objectdateien two.o und four.o in die Archivbibliothek libOne.a eingefuegt. Die Option -q sorgt dafuer, dass nicht ueberprueft wird, ob eine dieser Objectdateien bereits in der Archivbibliothek enthalten ist (wie man am Ergebnis in Zeile 7, 8 und 9 sehen kann). ar d libOne.a four.o entfernt die Objectdatei four.o wieder aus der Archivbibliothek.
Mit ar -t /usr/lib/libc.a | sort | less kann man sich alle Objectdateien aus der C-Standardbibliothek auflisten lassen. Um sich alle Funktionen aus einer Bibliothek (wie z. B. der C-Standardbibliothek) auflisten zu lassen, muss auf das Kommando nm (name mapper) zurueckgegriffen werden:

Das Kuerzel T in Zeile 7 bedeutet dabei, dass die Funktion hier definiert ist, waehrend U (Zeile(n) 4, 5 und 6) anzeigt, dass diese Funktion lediglich aufgerufen wird.

Dynamische Bibliotheken weisen einige Vorteile gegenueber statischen Bibliotheken auf:

Wie ueberall gibt es auch die Kehrseite der Medaille; die Nachteile der dynamischen Bibliotheken gegenueber statischen Bibliotheken sind folgende:

Ein wichtiger Grundsatz beim Entwurf von dynamischen Bibliotheken ist, dass diese immer abwaertskompatibel sein sollten. Das bedeutet, dass ein Programm, das mit einer aelteren Version dieser dynamischen Bibliothek gelinkt wurde, auch mit der neuen Version weiterhin lauffaehig sein sollte. Dieser Grundsatz muss nur dann nicht eingehalten werden, wenn eine voellig neue Version (major version) zu einer dynamischen Bibliotheken entwickelt wird. Jede dynamische Bibliothek hat einen speziellen Namen, den sogenannten soname, der dyn eigentlichen Namen der Bibliothek, sowie die Versionsnummer beinhaltet. Solange dynamische Bibliotheken abwaertskompatibel sind, also ihre Schnittstellen sich nicht aendern, sollte sich nur eine der Nummern (minor number) hinter der Hauptversionsnummer aendern.
Als Beispiel kann man die C-Bibliothek von Linux nehmen, die Abwaertskompatiblitaet fuer alle Unterversionen mit der gleichen Hauptversionsnummer garantiert. Da z. B. alle C-Bibliotheken mit der Hauptnummer 6 abwaerskompatibel sind, benutzen sie alle den gleichen soname (libc.so.6), der lediglich ein symbolischer Link auf die eigentliche, aktuelle dynamische Bibliothek ist:

Das Programm ldconfig sucht alle dynamischen Bibliotheken, die in bestimmten Directories liegen und erzeugt dann bei Bedarf einen symbolischen Link auf die jeweilige Version. ldconfigu untersucht standardmaessig immer die beiden Directories /lib und /usr/lib. Daneben untersucht es noch die Dateien der Directories, die auf der Kommandozeile beim Aufruf des Kommandos angegeben werden und die Directories, deren Namen sich in der Datei /etc/ld.so.conf befinden. Linkt man nun ein C-Programm, so wird der Linker immer nach einer Datei mit dem Namen /usr/lib/libc.so suchen, die ein symbolischer Link auf die gerade aktuelle dynamische C-Bibliothek ist. Um sich alle durch ldconfig eingerichteten symbolischen links anzeigen zu lassen, muss man nur ldconfig -p aufrufen. Benutzer, die eigene dynamische Bibliothekeb entwerfen wollen, sollten wissen, was zu beachten ist, damit eine neue dynamische Bibliothek abwaertskompatibel bleibt. Es gibt drei Arten von Aenderungen an einer dynamischen Bibliothek, die diese inkompatibel zu vorherigen Versionen werden laesst:

Dagegen ziehen die folgenden Modifikationen an einer dynamischen Bibliothek keine Inkompatiblitaet nach sich:

Beim Erzeugen von dynamischen Bibliotheken muss man sich an folgende Regeln halten:

Die Installation von dynamischen Bibliotheken erfolgt ueblicherweise mit dem Programm ldconfig. Um eine dynamische Bibliothek korrekt zu installieren, empfiehlt sich folgende Vorgehensweise:

In diesem Abschnitt wird das Programm fehler.c (die Datei eighdr.h ist hier zu finden) in eine dynamische Bibliothek umgewandelt, so dass es alle Programme die es ab jetzt benutzen moechten, nicht mehr statisch dazubinden musst. Hierzu sind folgende Schritte notwendig:

Jetzt wird fehlinfo.c kompiliert, das die eben erzeuge und installierte dynamische Bibliothek ausnutzt. Um die dynamische Bibliothek libfehler.so zum Programm fehlinfo dazu zu linken, empfiehlt sich die nachfolgend gezeigte Vorgehensweise:

Wenn man das erzeugte Programm fehlinfo startet, bekommt man folgende Ausgabe zu sehen:

Der Eintrag 'rand()%50+1;'in den Zeilen 13 und 22 von fehlinfo.c sorgt dafuer, dass die "Warnungen" abwechseln; die Ausgabe kann und wird also unterschiedlich ausfallen. Um die von einem Programm benoetigten dynamischen Bibliotheken zu erfahren, muss man lediglich das Kommando ldd mit dem entsprechenden Programmnamen aufrufen, wie z. B.:

Existiert sowohl eine dynamische wie auch eine statische Bibliothek zu einem Namen, so bindet der Linker automatisch die dynamische Bibliothek dazu, wenn er keine anderen Anweisungen enthaelt. Neben diesem einfachen Dazubinden von dynamischen Bibliotheken beim Linken, gibt es noch drei weitere Moeglichkeiten, dynamische Bibliotheken zu benutzen.

Startet man ein Programm, das dynamische Bibliotheken benutzt, versucht der dynamische Lader in dem Cache fuer Bibliotheken (/etc/ld.so.conf), der durch den Aufruf von ldconfig unter Zuhilfename der Datei /etc/ld.so.conf (enthaelt die Directories fuer dynamische Bibliotheken) erzeugt wurde, die vom Programm benutzten Bibliotheken zu finden. Ist jedoch die Environment-Variable LD_LIBARY_PATH gesetzt, werden zuerste die darin enthaltenen Directories, die wie bei PATH mit Doppelpunkt voneinander zu trennen sind, durchsucht, bevor der Cache herangezogen wird. So ist es moeglich, das man mit anderen Versionen von dynamischen Bibliotheken arbeitet, als die, welche instaliert sind. Dies mag z. B. notwendig sein, wenn man aeltere Programmversionen hat, die nicht mit einer neu installierten dynamischen Bibliothek ablauffaehig sind, dafuer aber mit einer aelteren Version dieser dynamischen Bibliothek. In diesem Fall kopiert man die aeltere Version in ein bestimmtes Directorie und setzt vor dem Programmstart die Environment-Variable LD_LIBARY_PATH entsprechend. Man kann auch ein Shellscript erstellen, dass wie folgt aussehen kann:

Fuer alt_bibl_dir ist das Directory anzugeben, in dem sich die aeltere Version der dynamischen Bibliothek befindet und fuer alt_programm ist der Name des zu startenden Programms anzugeben.

Manchmal moechte man nicht eine ganze dynamische Bibliothek, sondern nur einige Funktionen ersetzen. Da der dynamische Lader nach Funktionen sucht, indem er bei der ersten geladenen Bibliothek beginnt und dann in den anderen Bibliotheken in der Reihenfolge fortfaehrt, in der diese geladen wurden, reicht es zunaechst aus, nur eine neue Bibliothek zu laden, die nur die neuen Funktionen enthaelt, die zu ersetzen sind. Ein Beispiel hierzu ist die Bibliothek zlibc, die Funktionen, welche von der C-Bibliothek zur Dateibearbeitung angebogen werden, durch eigene Funktionen ersetzt, die mit komprimierten Dateien arbeiten koennen, Wird eine Datei geoeffnet, sucht zlibc sowohl nach der angegebenen Datei als auch nach einer mit gzip gepackten Version dieser Datei. Findet es die angegebenen ungepackte Datei, verhaelt sich die entsprechende Funktion genauso wie die Version dieser Funktion in der C-Bibliothek. Existiert die angegebene Datei aber nicht, dafuer aber eine gepackte Version dieser Datei, entpackt sie diese, ohne dass sich das aufrufende Programm darum muss. Um eine Bibliothek vorzuladen, gibt es zwei Moeglichkeiten.

Zum ersten das Setzen der Environment-Variable LD_PRELOAD LD_PRELOAD=/lib/vorlad.o exec /bin/programm $* und zum zweiten mit dem Eintragen der vorzuladenden Objectdateien in die Datei /etc/ld.so.preload. Fuer die Bibliothek zlibc koennte die folgende Zeile in die Datei /etc/ld.so.preload eingetragen werden: /lib/uncompress.o

Groessere Softwarepakete werden unter Linux/Unix ueblicherweise in Module zerlegt, die getrennt voneinander entwickelt werden. Manchmal sind diese Module eigenstaendige Programme, die mit anderen Modulen des Softwarepakets ueber Pipes oder andere Formen der Interprozesskommunikation kommunizieren. Eine andere Moeglichkeit der Kommunikation ist die Implementierung von sogenannten shared objects (geteilte Objecte). Solche shared objects koenen entweder Objectdateien oder dynamische Bibliotheken sein. da der Linker nicht von den shared objects wissen muss, ist es noch nicht einmal erforderlich, dass diese zum Zeitpunkt des Linkens existieren muessen. Ein weiterer Unterschied von shared objects zu dynamischen Bibliotheken ist, dass sie anders installiert werden wie die meisten dynamischen Bibliotheken.

Daneben muessen die von shared objects verwendeten Symbolnamen nicht eindeutig und einmals sein, was sie meist auch nicht sind, da verschiedene shared objects, die fuer die gleiche Schnittstelle entwickelt wurden, normalerweise auch Eintrittspunkte mit den gleichen Namen verwenden, was bei dynamischen Bibliotheken absolut unmoeglich ist.

Die haeufigste Anwendung von shared objects sind sogenannte generische Schnittstellen. Diese snid im Prinzip nicht anderes als Funktionszeiger, denen erst zur Laufzeit die Adresse der entsprechenden Funktion zugewiesen wird. So ist es moeglich, dass Programme beliebig erweiterbar sind, ohne das sie erneut kompiliert oder gelinkt werden muessen. Ein Beispiel fuer die Verwendung von generischen Schnittstellen koennte ein Programm sein, dass Simulationen fuer Industrieprozesse nach verschiedenen Verfahren durchfuehren kann. Diese Programm verwendet intern ein eigenes Format, um die berechneten Werte grafisch am Bildschrim darzustellen. Wird nur eine generische Schnittstelle geschafft, die die Durchfuehrung der Simulation in zur Laufzeit geladene shared objects verlagert, kann jederzeit ein neues Simulationsverfahren hinzugefuegt werden, ohne das diese Programm neu kompilier/gelinkt werden muss. Generische Schnittstellen setzen allerdings immer eine gute Dokumentation ihrer Funktionsweise voraus, damit auch andere Programmierer, die die Interna des jeweiligen aufrufenden Hauptprogramms nicht kennen, sie benutzen und so den Funktionsumfang des Hauptprogramms erweitern koennen. Dynamisches Laden erfordert folgende Aktivitaeten:

Die hierzu notwendigen Funktionen dlopen, dlsym, dlerror und dlclose sind in der Headerdatei dlfcn.h deklariert.

dlopen laedt die dynamische Bibliothek, deren Name ueber den Parameter filename angegeben ist und gibt einen Zeiger zurueck, mit dem nun Zugriffe (mit den Funktionen dlsym und dlclose) auf diese Bibliothek moeglich sind. Wird fuer filename ein absoluter Pfad (beginnen mit /) angegeben, muss dlopen die Bibliothek nicht suchen. Die ist der uebliche Weg um dlopen aufzurufen. Ist der fuer filename angegebener Pfad kein absoluter Pfad, sucht dlopen die entsprechende Bibliothek an den folgenden Stellen in der angegebenen Reihenfolge:

Gibt man fuer filename den NULL-Zeiger an, oeffnet dlopen die Datei des aktuell ausgefuehrten Programms (was aber nur in sehr wenig Faellen sinnvoll ist). Undefinierte externe Referenzen in der dynamischen Bibliothek werden aufgeloest, indem andere zuvor mit RTLD_GLOBAL geoeffnete Bibliotheken und die Bibliotheken durchsucht werden, die in der Abhaengigkeitsliste dieser Bibliothek enthalten sind. Fuer flag kann eine der folgenden Konstanten angegeben werden:

Enthaelt eine dynamische Bibliothek eine Funktion namens _init, wird diese ausgefuehrt, bevo dlopen zurueckkehrt. Wird die gleiche Bibliothek mehrmals geoeffnet, dann wird immer der gleiche Zeiger (handle) zurueckgegeben. Mit bitweisem OR (|) kann RTLD_GLOBAL mit RTLD_NOW und RTLD_LAZY verknuepft werden.

dlsym sucht in der Bibliothek handle, was der Rueckgabewert der zuvor mit dlopen erfolgreich geoeffneten Bibliothek sein muss, nach dem Symbol mit dem Namen symbol. dlsym liefert die Adresse, an die dieses Symbol geladen wurde, oder, falls dieses nicht gefunden werden koennte, den NULL-Zeiger. Da es aber Symbole geben kann, die die Adresse NULL haben, laesst dieser Rueckgabewert nicht unbedingt auf einen Fehler schliessen. Deswegen ist es in diesem Fall empfehlenswert, die nachfolgende Funktion dlerror heranzuziehen, um eine Fehlerueberpruefung durchzufuehren.

gibt NULL zurueck, wenn kein Fehler seit dem Oeffnen der dynamischen Bibliothek oder seit dem letzten Aufruf von dlerror aufgetreten ist, oder aber die Adresse der entsprechenden Fehlermeldung. Da jeder Aufruf von dlerror dazur fuehrt, dass eine eventuell vorhandene Fehlermeldung nach diesem Aufruf nicht mehr zur Verfuegung steht, sollte man diese Fehlermeldung in einer eigenen Variable speichern, wenn man sie fuer spaetere Zwecke wieder benoetigt.

Jedesmal wenn dlopen eine Bibliothek oeffnet, wird ein internet Referenzzaehler erhoeh. Dieser Referenzzaehler wird bei jedem Aufruf von dlclose um 1 erniedrigt. Erst wenn dieser Referenzzaehler bedingt durch einen dlclose-Aufruf 0 wird, wird auch die Bibliothek geschlossen und der fuer sie allokierte Speicherplatz freigegeben. Enthaelt die dynamische Bibliothek eine Funktion namens _fini, wird diese ausgefuehrt, bevor dlclose zurueckkehrt. Durch den Referenzzaehler ist es moeglich, beliebig oft die entsprechende Bibliothek zu oeffnen und zu schliessen, ohne sich darum kuemmern zu muessen, ob die zugehoerigen shared objects bereits vom aufrufenden Code geladen wurden. Wenn diese Funktionen in einem Programm verwendet werden, muss man beim linken dieses Programms die Bibliothek libdl.so mit der Option -ldl dazulinken.

Das Programm sinus.c demonstriert das dynamische Laden eines shared object, indem es die Funktion sin aus der mathematischen Bibliothek laedt, um sie im Programm verwenden zu koennen. Nachdem man das Programm mit cc -o sinus sinus.c fehler.c -ldl kompiliert und gelinkt hat, kann man es starten, indem man ihm den Pfadnamen der mathematischen Bibliothek als Argument auf der Kommandozeile uebergibt:

Nun soll aber eine eigene Funktion sin erstellt werden, die nicht den Sinus berechnet, sondern nur das Doppelte des uebergebenen Werts zurueckliefert, wie dies in folgendem Programm umgesetzt wird:

Aus diesem Programm (sin.c) wird mit den folgenden Aufrufen eine dynamische Bibliothek erstellt:

Startet man das Programm sinus erneut und uebergibt ihm aber diesmal die eigene dynamische Bibliothek sin.so.1 im Working-Directory, verwendet es nur das shared object sin aus der eigenen Bibliothek:

Hier sieht man also, dass beim Arbeiten mit shared objects also ein einfaches Austauschen von Funktionen moeglich ist, ohne dass die Originalprogramme erneut kompiliert und/oder gelinkt werden muessen.