Programmbibliotheken

Transkript

1 Programmbibliotheken Holger Jakobs Inhaltsverzeichnis 1 Separate Compilation Zerlegung von Programmen in Module Die Headerdateien Compilation von Modulen Warum Bibliotheken? 3 3 Standard-Bibliotheken 5 4 Arten von Bibliotheken 5 5 Linux-Bibliotheken Archive Libraries Shared Libraries Auswahl des Library Typs beim Compilieren Erzeugen eigener Archive Libraries Erzeugen eigener Shared Libraries Verwenden eigener Shared Libraries Aktualisieren eigener Shared Libraries Separate Compilation Alle Programme mit Ausnahme einiger klitzekleiner, die meist nur zu Übungszwecken geschrieben werden werden bei der Entwicklung in mehrere Module zerlegt. Unter Modul versteht man bei C eine Quelltextdatei, die üblicherweise die Dateinamenserweiterung.c trägt. 1.1 Zerlegung von Programmen in Module Genau eine der Quelltextdateien enthält eine Funktion namens main(), das Hauptprogramm. Diese Funktion wird beim Programmstart automatisch aufgerufen, weshalb der 1

2 1.2 Die Headerdateien 1 SEPARATE COMPILATION Name auch vorgeschrieben ist. Alle anderen Funktionsnamen sind völlig frei wählbar, dürfen aber nicht mit reservierten Wörtern von C und den in der Standardbibliothek verwendeten Funktionsnamen kollidieren. Das Programm kann man beliebig auf verschiedene Quelltextdateien verteilen, wobei man üblicherweise die Funktionen ihrer Aufgabe gemäß in Gruppen zusammenfasst und gemeinsam in eine Datei schreibt. 1.2 Die Headerdateien Damit beim Compilieren des Hauptprogramms die in den anderen Modulen definierten Funktionen bekannt sind, schreibt man zu den Funktionen sogenannte Headerdateien, die üblicherweise die Dateinamenserweiterung.h tragen. Die eigenen Headerdateien werden beim Compilerlauf durch #include "Headerdateiname " eingebunden im Gegensatz zu den System-Headerdateien, wo #include <Headerdateiname > verwendet wird. Dabei werden sie so gelesen, als stünde der Dateiinhalt an der Stelle der #include-anweisung. Headerdateien können folgendes enthalten: Prototypen der in der zugehörigen Quelltextdatei enthaltenen Funktionen Konstanten Datentyp-Definitionen, z. B. Strukturen; bei C++ auch Klassen evtl. auch Variablen, z. B. die Variable errno in der Headerdatei errno.h Oft ist es so, dass Funktionen nicht nur direkt vom Hauptprogramm, sondern auch von anderen Modulen benutzt werden. Da kommt es vor, dass eine Headerdatei von einem Quelltext mehrfach (direkt und zusätzlich indirekt) per #include eingebunden wird. Tatsächlich aber darf sie nur einmal ausgewertet werden, weil eine Mehrfachdeklaration von Funktionen, Konstanten und Variablen zu Fehlern führen kann. Um die mehrfache Auswertung zu verhindern, verwendet man einen sogenannten Include Guard. Dieser setzt sich aus Präprozessoranweisungen zusammen und sieht beispielsweise so aus: #ifndef _BEISPIELHEADER_H #define _BEISPIELHEADER_H /* eigentlicher Inhalt der Headerdatei */ #endif Es wird zunächst gefragt, ob das Symbol (hier _BEISPIELHEADER_H) vorhanden ist. Das ist beim ersten Includen der Datei natürlich nicht der Fall. Daraufhin wird das Symbol definiert, und der eigentliche Inhalt der Datei wird gelesen und verarbeitet. Das #endif schließt den if-zweig. 2

3 2 WARUM BIBLIOTHEKEN? 1.3 Compilation von Modulen Wird die Datei im selben Compilerlauf ein weiteres Mal gelesen, so wird festgestellt, dass das Symbol (hier _BEISPIELHEADER_H) bereits definiert wurde. Also wird alles bis zum #endif übersprungen, die Datei also nicht erneut ausgewertet. Der Name des verwendeten Symbols ist völlig gleichgültig. Um aber sicherzustellen, dass nicht dasselbe Symbol in verschiedenen Headerdateien verwendet wird, leitet man es oft vom Namen der Headerdatei ab. Da Punkte nicht zugelassen sind, werden statt dessen Unterstriche verwendet. 1.3 Compilation von Modulen Möchte man die Module auf syntaktische Korrektheit testen, so kann man jedes einzeln compilieren aber natürlich nicht linken, weil keine main()-funktion dabei ist. Daher verwendet man die Compiler-Option -c (compile only don t link). Hat man alle Module entwickelt, kann man sie zu einer ausführbaren Datei zusammenlinken. Hier gibt man dann alle.o-dateien an. Der Compiler erkennt, dass es sich nicht um Quelltexte, sondern um bereits compilierte Object-Dateien handelt. Man kann auf der Kommandozeile auch durchaus Quelltexte und Object-Dateien mischen: die einen werden compiliert, die anderen nur gelinkt. Zum Link-Zeitpunkt müssen alle Referenzen (auf Funktionen, Konstanten und Variablen) aufgelöst werden können. Das kann durch Objekte in derselben Object-Datei geschehen, durch Objekte in einer der anderen genannten Object-Dateien oder auch durch die Standard-Bibliothek, die immer automatisch dazugelinkt wird. 2 Warum Bibliotheken? Bei der Programmierung in C unter Unix verwendet man fast immer Bibliotheken. Einige davon werden standardmäßig beim Aufruf des C-Compilers verwendet; d. h. man muss sie nicht selbst angeben, sondern sie werden in der Link-Phase automatisch verwendet, wie im vorigen Abschnitt bereits erwähnt. Wenn man eigene Programme in viele Module zerlegt, kann man alle Object-Dateien immer angeben. Wenn sich aber ein Teil der Object-Dateien nicht mehr regelmäßig ändert, weil ihre Entwicklung weitgehend abgeschlossen ist, kann man diese zu einer Bibliothek zusammenfassen und muss von nun an nur noch diese eine Datei statt der evtl. sehr langen Liste einzelner Object-Dateien beim Compilieren bzw. Linken angeben. Dies ist insbesondere dann praktisch, wenn man eine eigene Funktionssammlung in mehreren Programmierprojekten verwendet. Gleiches gilt auch für andere Zusatzbibliotheken seien es welche aus dem Lieferumfang des Rechnersystems oder auch separat hinzu gekaufte. Bei cc handelt es sich um ein binäres Programm, wo man die einzelnen Phasen mittels der Option -v (für verbose) sichtbar machen kann. Bei manchen C-Compilern (z. B. bei der GNU Compiler Collection) werden die einzelnen Compilerphasen (Parser, Codegenerator, Assembler, Optimizer) und der Linker von diesem aufgerufen; bei einigen (z. B. beim C- Compiler von HP-UX) ist der Compiler nur ein Programm, das lediglich den Linker separat 3

4 2 WARUM BIBLIOTHEKEN? aufruft. Der Link-Aufruf für die Object-Datei bsp.o sieht (bei HP-UX 10.2) so aus: /usr/ccs/bin/ld /opt/langtools/lib/crt0.o -u main bsp.o -lc Was bedeutet dieser Aufruf? Es wird die Datei /opt/langtools/lib/crt0.o mit dem Object-File bsp.o des gerade übersetzten Quellprogramms gelinkt. Das Symbol main wird in bsp.o gesucht und die Bibliothek /lib/libc.so /lib/libc.a verwendet. Die Option-lc gibt an, dass die Bibliothek libc verwendet werden soll; diese hat üblicherweise die Namensendung.so (bei dynamischer Bibliothek) oder.a (bei statischer Bibliothek) und befindet sich im Verzeichnis /lib. Es werden (mindestens) die Verzeichnisse /lib und /usr/lib nach ihr durchsucht. Weitere zu durchsuchende Verzeichnisse kann man mit der Option -L angeben. Bei Linux (SuSE 6.4) sieht der Aufruf anders aus (alles in einer Kommandozeile): /usr/lib/gcc-lib/i486-linux/egcs /collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/egcs /crtbegin.o -L/usr/lib/gcc-lib/i486-linux/egcs L/usr/i486-linux/lib bsp.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/egcs /crtend.o /usr/lib/crtn.o Wie man sieht, werden hier viel mehr Dateien eingebunden und Optionen angegeben. Standardmäßig werden bei Linux wie mittlerweile bei fast allen Unix-Varianten dynamische Bibliotheken verwendet. Die Datei crt0.o von HP-UX verteilt sich bei Linux auf mehrere Dateien, deren Namen alle mit crt beginnen. Es werden auch einige zusätzlich nach Bibliotheken zu durchsuchende Verzeichnisse mittels der Option -L angegeben. Die Datei crt0.o bzw. die Dateien crt*.o dienen dazu, die Umgebung einzulesen (u. a. die Kommandozeilenargumente) und die Funktion main()-funktion aufzurufen. Bei Aufruf von exit() oder bei Verlassen der main()-funktion schließt der Code aus crt*.o alle offenen Dateien und beendet den Prozess. Sollte im Hauptprogramm (oder in einer anderen enthaltenen.o-datei) ein Funktionsaufruf oder eine Referenz auf eine Variable enthalten sein, die nicht in der Standardbibliothek vorhanden ist, so gibt es eine entsprechende Fehlermeldung, und die Datei a.out wird nicht als ausführbar gekennzeichnet. Das kann z. B. so aussehen: HP-UX: /usr/ccs/bin/ld: Unsatisfied symbols: exp (code) Linux: /tmp/cca o: In function main : /tmp/cca o(.text+0x1b): undefined reference to exp Hier wurde der Aufruf der Exponentialfunktion (exp()) nicht gefunden, denn die Funktion 4

5 4 ARTEN VON BIBLIOTHEKEN befindet sich in der Mathematikbibliothek /lib/libm.so bzw. /lib/libm.a, die beim Compileraufruf nicht angegeben wurde. Die Datei crt0.o wird verwendet, um die Umgebung einzulesen (u. a. die Kommandozeilenargumente) und ruft anschließend main() auf, so dass das eigentliche Programm dann startet. 3 Standard-Bibliotheken Ohne weitere Angaben werden die folgenden Funktionen immer dazugelinkt, weil sie Bestandteil der libc (Standardbibliothek für C) sind. In Klammern davor steht das Kapitel der man-pages, in denen sie dokumentiert sind: (2) Unix-Systemaufruf-Bibliothek (3) Standard-C-Bibliothek einschließlich Standard-Ein-Ausgabebibliothek Zu den weiteren häufig benutzten Bibliotheken gehören beispielsweise: libcurses, Header <curses.h> Bibliothek zur Bildschirmsteuerung auf Textterminals libm, Header <math.h> Mathematik-Bibliothek libdes, Header <des.h> Verschlüsselungs-Bibliothek (Data Encryption Standard) libdb, Header <db.h> Datenbank-Bibliothek (einfach, kein SQL) libpthread, Header <pthread.h> Erzeugen und Verwalten von POSIX-Threads (Teilprozesse). 4 Arten von Bibliotheken Bei vielen Unix-Varianten gibt es zwei Arten von Bibliotheken: archive (statische) und shared (dynamische) Bibliotheken. Statische Bibliotheken sind die klassischen, bei denen in das ausführbare Programm der gesamte notwendige Code geschrieben wird. Bei Verwendung von vielen und großen Bibliotheken hat das jedoch zwei gravierende Nachteile: Die Programme werden unnötig groß und enthalten weitestgehend alle denselben Code. Bei Updates der Bibliotheken muss man alle Programme erneut linken, um in den Genuss der evtl. Verbesserungen zu kommen. 5

6 5 LINUX-BIBLIOTHEKEN Im folgenden sollen die Erzeugung und Verwendung von dynamischen Bibliotheken bei Linux dargestellt werden. 5 Linux-Bibliotheken Bei Linux sind fast alle Bibliotheken sowohl als Archive als auch als Shared Library vorhanden. Sofern beide im selben Verzeichnis vorhanden sind, verwendet der Linker die dynamische Version, ansonsten diejenige, die er zuerst findet. Archive Libraries haben die Endung.a, Shared Libraries die Endung.so, was für shared object steht, haben sonst aber denselben Namen. Die Standard-Bibliotheken gibt es bei Linux in mehreren Varianten, die durchnumeriert sind. Die Numerierung geht bis zu 3 mit Punkten getrennten Stellen, wobei alle Bibliotheken mit identischer erster Stelle voll kompatibel sein müssen. Im allgemeinen gibt es einen symbolischen Link von libc.so.x auf libc.so.x.y.z, d. h. auf die neueste Version. Die Standard-C-Bibliothek existiert also als /lib/libc.so.6 und als Archive Library im Verzeichnis /usr/lib als /usr/lib/libc.a. Nur die Shared-Variante muss zum Systemstart vorhanden sein, während die Archive-Variante ruhig erst später auf einem gemounteten Filesystem liegen darf. Wenn man selbst Bibliotheken erzeugen möchte, kann man dies in Form von Archive oder in Form von Shared Libraries tun. Archive Libraries werden mit Hilfe des Programms ar erzeugt, Shared Libraries mit Hilfe des Linkers ld oder auch durch den indirekten Aufruf mittels des Compilers (z. B: cc). Damit Object Files zu Shared Libraries verarbeitet werden können, müssen sie position-independent code enthalten, was man durch die Compiler- Option -fpic (bzw. -fpic) erreicht. 5.1 Archive Libraries Archive Libraries bestehen aus einem oder mehreren Object Files. Beim Linken werden die benötigen Module aus der Archive Library in die ausführbare Datei (z. B. a.out) kopiert. Jedes Programm, das die Funktion printf() aus der Archive Library verwendet, enthält also den vollständigen Object Code von printf(). 5.2 Shared Libraries Shared Libraries enthalten ebenfalls Object Code, aber der Linker geht mit Shared Libraries anders um als mit Archive Libraries. Beim Link-Vorgang werden die Module mit dem Object Code nicht in die ausführbare Datei kopiert, sondern es wird dort nur vermerkt, dass ein Aufruf einer Funktion aus einer Shared Library erfolgt. Ruft man eine nicht vorhandene Funktion, stellt der Linker das also fest. Die entstehende ausführbare Datei (z. B. a.out) enthält also nicht sämtlichen benötigten Code und wird daher auch als unvollständig bezeichnet. Startet man eine unvollständige ausführbare Datei, so prüft der dynamische Lader (siehe >man 8 ld.so), welche Bibliotheken die ausführbare Datei benötigt. Daraufhin werden die 6

7 5 LINUX-BIBLIOTHEKEN 5.3 Auswahl des Library Typs beim Compilieren Bibliotheken geladen und den Aufrufen zugeordnet. Hierbei werden die Bibliotheken auf vielfältige Art gesucht, zum Teil mit Hilfe von Systemdateien im Verzeichnis /etc und mit Angaben in Umgebungsvariablen (LD_LIBRARY_PATH, LD_PRELOAD). Shared Libraries führen zu deutlich kleineren Programmen, was Plattenplatz spart. Da derselbe Code auch im Hauptspeicher von mehreren Prozessen benutzt wird, ist auch hier eine deutliche Einsparung gegeben. Hierzu ein Beispiel: Datei Bytes Quelltext wordcount.c 1127 Object-File wordcount.o 1712 Ausführbare Datei mit Archive Library Ausführbare Datei mit Shared Library 4004 Die Übersetzung wurde durchgeführt mit cc -c wordcount.c, das Linken mit cc wordcount.o, beim Erzeugen eines statischen Programms mit cc -static wordcount.o. In beiden Fällen wurde die ausführbare Datei mit strip a.out von Symbol-Informationen befreit (siehe auch Manpage zu strip). Verwendet wurden egcs und GNU ld Auswahl des Library Typs beim Compilieren Möchten Sie beeinflussen, welche Art von Bibliotheken benutzt wird, können Sie die Optionen direkt beim Link-Vorgang angeben: -Bstatic. Da man den Linker aber selten direkt aufruft, gibt es auch die Möglichkeit, dem GNU Compiler die Option -static mitzugeben, der diese dann an den Linker weiterreicht. 5.4 Erzeugen eigener Archive Libraries Archive Libraries werden mit Hilfe des Programms ar aus Object Files erzeugt. Dies geschieht auf allen Unix-Systemen auf dieselbe Art und Weise. Die Aufruf-Syntax ist: ~>ar r libname.a obj1.o obj2.o... r ist die Operation für ar, mit der anschließend genannten Bibliothek zu arbeiten und die danach genannten Object Files in der Bibliothek zu ersetzen (replace). Da die Bibliothek noch nicht existiert, wird sie angelegt; und da die Object Files noch nicht enthalten sind, werden sie nicht ersetzt, sondern hinzugefügt. Mit Hilfe der Operation t (table of content, Inhaltsverzeichnis) für das Programm ar können Sie nachschauen, ob alle Object Files wirklich enthalten sind (tv gibt ausführliches Listing, v=verbose=ausführlich): ~>ar t libname.a Die Bibliothek ist nun mit dem Compiler verwendbar, wenn man sie auf der Kommandozeile mit angibt: 7

8 5.5 Erzeugen eigener Shared Libraries 5 LINUX-BIBLIOTHEKEN ~>cc progname.c libname.a Stellen Sie die Bibliothek in eines der Verzeichnisse /lib oder /usr/lib, so könnten Sie auch folgende Kommandozeile verwenden, sofern der Name der Bibliothek mit lib beginnt und auf name.a endet: ~>cc progname.c -lname Üblicherweise können Sie Ihre Bibliotheken jedoch nicht in eines dieser Verzeichnisse stellen, wenn Sie nicht root sind. Allerdings können Sie Ihr eigenes Bibliotheksverzeichnis z. B. als $HOME/lib anlegen und mit der Option -L $HOME/lib den Linker anweisen, auch dieses Verzeichnis zu durchsuchen. Um weitere Module hinzuzufügen oder Module zu ersetzen, verwenden Sie wie bei der Erzeugung der Archive Library die Operation r. Geben Sie zusätzlich u (update) an (~>ar ru...), wenn Sie nur die Module ersetzen möchten, die neuer sind als die enthaltenen. Um einzelne Module zu löschen, ohne die ganze Bibliothek neu erstellen zu müssen, verwenden Sie die Operation d (delete): ~>ar d libname.a obj2.o Um Module aus einer Library wieder herauszuholen und erneut als.o-datei zu speichern, verwenden Sie die Operation x (extract): ~>ar x libname.a obj3.o Für nähere Informationen zum Programm ar schauen Sie bitte ins Online-Manual: man ar. Hierbei sei insbesondere auf die v und s verwiesen. v kann mit allen anderen Anweisungen gemeinsam verwendet werden, s sowohl allein als auch gemeinsam mit anderen. 5.5 Erzeugen eigener Shared Libraries Zunächst einmal muss der erzeugte Code geeignet sein, in Shared Libraries verwendet zu werden, was Sie mit der Option -fpic(oder -fpic) sicherstellen: ~>cc -c -fpic quell.c Grundsätzlich sind -fpic und -fpic identisch. Üblicherweise verwenden Sie -fpic; nur wenn Sprünge über größere Distanzen erforderlich sind und der Linker dies meldet, müssen Sie mit -fpic compilieren. Teilweise wird auch empfohlen, immer -fpic zu benutzen. Shared Libraries werden prinzipiell genau wie ausführbare Programme erzeugt. Der Unterschied besteht darin, dass man die Option -shared angibt. ~>ld -shared -o librechne.so add.o sub.o Dieses Kommando erzeugt die Bibliothek librechne.so aus den beiden Object Files add.o und sub.o. Shared Libraries sind als ausführbar gekennzeichnet. Alle Benutzer, die sie verwenden sollen, müssen auch Ausführungsrecht für diese Bibliothek haben. Die Bibliothek kann nun für die Erzeugung von Programmen benutzt werden: ~>cc prog.c librechne.so -o prog 8

9 5 LINUX-BIBLIOTHEKEN 5.6 Verwenden eigener Shared Libraries 5.6 Verwenden eigener Shared Libraries Wenn man jetzt das Program prog ausführen möchte, könnte es sein, dass es einen Fehler vom Loader gibt: a.out: error in loading shared libraries: Bibliotheksname.so: cannot open shared object file: No such file or directory Das hängt damit zusammen, dass sich die Bibliothek im aktuellen Verzeichnis befindet, die üblicherweise nicht nach dynamischen Bibliotheken durchsucht wird. Damit es doch geschieht, muss man das aktuelle Verzeichnis in den Suchpfad aufnehmen: LD_LIBRARY_ PATH=$LD_LIBRARY_PATH:. Die Variable LD_LIBRARY_PATH ist prinzipiell genauso aufgebaut wie die PATH-Variable für ausführbare Dateien, gibt aber an, wo dynamische Bibliotheken gesucht werden. Durch Änderung dieser Variablen ist es möglich, einem Programm eine andere dynamische Bibliothek unterzuschieben Sicherheitslücke! Stellt man Shared Libraries, deren Name mit lib beginnt und auf.so endet, in eines der Verzeichnisse /lib oder /usr/lib, so kann man sie (genau wie Archive Libraries auch) mit der Option -l einbinden. Auch hier kann die Liste der Verzeichnisse, die nach Bibliotheken durchsucht werden, mit der Option -L erweitert werden, so dass auch dynamische Bibliotheken in privaten Bibliotheksverzeichnissen (z. B. $HOME/lib) abgelegt werden können. Da sie aber auch beim Starten der Programme noch einmal benötigt werden, ist es notwendig, die Umgebungs-Variable LD_LIBRARY_PATH zu erweitern, z. B. mit dem Kommando LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/lib. Das schreibt man dann genau wie die Erweiterung der Variablen PATH für ausführbare Dateien in die Datei $HOME/.profile. 5.7 Aktualisieren eigener Shared Libraries Das Aktualisieren von Shared Libraries geht leider nicht so einfach wie bei Archive Libraries; man muss immer wieder sämtliche Object Files zu einer neuen Shared Library zusammenbinden, weshalb man sich dafür am besten ein Makefile erstellt (siehe z. B. man make und die Unterlagen zu Make aus dem BES-Portal). Hinweis: Nachdem man eine Shared Library aktualisiert hat, verwenden alle Programme, die mit der alten Version gelinkt wurden, die Routinen aus der neuen Library! Es ist einerseits ein großer Vorteil, dass man nicht alle Programme neu linken muss, kann aber auch zu Problemen führen, wenn man die Parameterliste oder die Funktionalität einer Funktion geändert hat. Aus diesem Grunde gibt es von Bibliotheken verschiedene Versionen, die zwar den selben Grundnamen tragen, aber verschiedene Versionsnummern im Dateinamen, wobei auf die jeweils aktuellste Version ein symbolischer Link gesetzt wird. Das kann man auch schon bei einigen Standardbibliotheken feststellen: lrwxrwxrwx 12 Oct libform.so -> libform.so.5 lrwxrwxrwx 14 Apr libform.so.4 -> libform.so.4.2 -rwxr-xr-x Nov 13 11:27 libform.so.4.2 lrwxrwxrwx 14 Oct libform.so.5 -> libform.so.5.0 -rwxr-xr-x Nov 13 11:27 libform.so.5.0 9

10 5.7 Aktualisieren eigener Shared Libraries 5 LINUX-BIBLIOTHEKEN Eine andere Möglichkeit ist, eine neue Funktion zu erstellen und die alte Funktion unverändert beizubehalten. Auch das ist in den Unix-Standardbibliotheken gemacht worden, beispielsweise bei random() und rand(). $RCSfile: Bibliotheken.tex,v $ $Date: 2004/06/16 13:23:15 $ $Revision: 1.6 $ 10