Copyright © 1995 by O'Reilly/International Thomson Verlag
Bitte denken Sie daran: Sie dürfen zwar die Online-Version
ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.
Wünschen Sie mehr Informationen zu der gedruckten
Version des Buches "Linux - Wegweiser zur Installation & Konfiguration",
dann klicken Sie
hier.
Linux ist ein Ziel, das sich sehr schnell bewegt. Aufgrund der kooperativen
Entstehungsweise dieses Projektes erscheint ständig neue Software, und
Programme werden immer wieder durch neuere Versionen ersetzt. Dies gilt
insbesondere für den Linux-Kernel, an dem viele Gruppen von
Programmierern mitarbeiten. Es ist durchaus nicht ungewöhnlich, daß
in der Entwicklungsphase jede Nacht ein neuer Kernel-Patch erscheint. Obwohl
andere Teile des Systems nicht ganz so dynamisch sind, gilt das eben Gesagte
im Prinzip auch hier.
Wie kann man sicher sein, daß man immer die aktuelle Version der
Systemsoftware benutzt? Die einfache Antwort lautet: gar nicht. Sicherlich
gibt es Leute dort draußen, für die es wichtig ist, daß sie
z.B. einmal täglich die neueste Version eines Kernel-Patches einspielen,
aber für die meisten von uns besteht kein Grund, das System so oft auf
den aktuellen Stand zu bringen. In diesem Abschnitt wollen wir die Frage
behandeln, warum und wann man updaten sollte und wir werden Ihnen zeigen, wie
sie wichtige Teile des Systems auf dem aktuellen Stand halten.
Wann sollte man ein Update vornehmen? Allgemein gesagt, sollten Sie nur dann
updaten, wenn Sie erwiesenermaßen einen
Bedarf
dafür festgestellt haben. Wenn Sie z.B. von der neuen Version eines
Programms hören, in der gravierende Fehler beseitigt sind (d.h. Fehler,
die Auswirkungen auf Ihre Arbeit mit diesem Programm haben), könnte das
ein Grund sein, die neue Version zu besorgen. Wenn die aktuelle Version eines
Programms Bestandteile enthält, die für Sie von Nutzen sein
könnten oder wenn sie wesentlich schneller läuft als Ihre jetzige
Version, ist es ebenso angebracht, auf die neue Version umzusteigen. Dagegen
ist es wahrscheinlich keine allzu gute Idee, ein Update vorzunehmen, nur um
die neueste Version eines bestimmten Programms zu haben.
Ein Update kann eine schmerzvolle Angelegenheit werden. Das gilt z.B. dann,
wenn Sie neben dem Update des Programms auch die neueste Version des
Compilers, der Libraries und noch andere Software benötigen. In dem Fall
müssen Sie weitere Teile des Systems erneuern, bevor Sie die neue
Programmversion installieren können, was eventuell erhebliche Zeit in
Anspruch nimmt. Andererseits kann man dies auch als ein Argument dafür
betrachten, daß die Software auf dem neuesten Stand gehalten werden
sollte -- wenn Compiler und Libraries aktuell sind, wird es kein Problem sein,
das betreffende Programm auf den aktuellen Stand zu bringen.
Wie erfährt man von neuen Versionen der Linux-Software? Die beste Methode
ist das Lesen der USENET-Newsgruppe
comp.os.linux.announce
(lesen Sie hierzu auch den Abschnitt
»
USENET-Newsgruppen
«
in
Kapitel 1,
Einführung in Linux
), in der Ankündigungen neuer Softwareversionen und andere wichtige
Informationen veröffentlicht werden. Wenn Sie Zugang zum Internet haben,
können Sie sich die Software dann per FTP besorgen und auf Ihrem System
installieren.
Ohne einen Zugang zum USENET oder Internet bleiben Sie am besten auf dem
aktuellen Stand der Dinge, indem Sie ein CD-ROM-Abonnement bestellen. Auf
diese Weise bekommen Sie ca. alle zwei Monate einen aktuellen Abzug der
verschiedenen Linux-FTP-Server auf CD-ROM. Diesen Service bieten einige
Linux-Händler an. Ein solches Abonnement ist selbst dann eine gute Idee,
wenn Sie über einen Zugang zum Internet verfügen.
Damit sind wir bei einem anderen Thema -- welches ist die beste
Update-Methode? Manche Leute sind der Meinung, daß es einfacher ist, das
System komplett neu zu installieren, wenn eine neue Version ihrer
Lieblingsdistribution erscheint (z.B. Slackware). Dann muß man sich
keine Gedanken darüber machen, ob die verschiedenen Versionen der
Software miteinander funktionieren. Dies mag für Leute ohne Zugang zum
Internet richtig sein -- wenn Sie aber nur alle zwei Monate eine neue CD-ROM
beziehen, kann ein großer Teil der Software bereits wieder veraltet
sein.
Wir sind allerdings der Meinung, daß eine komplette Neuinstallation
keine sinnvolle Art des Updates ist. Die meisten der aktuellen
Linux-Distributionen sind nicht für diese Methode der
Systemaktualisierung gedacht, und die Neuinstallation kann eine sehr
komplizierte oder zeitaufwendige Angelegenheit sein. Außerdem verlieren
Sie bei dieser Art des Updates in der Regel alle Änderungen und
Anpassungen, die Sie am System bereits vorgenommen haben. Bedenken Sie auch,
daß Sie die Home-Verzeichnisse der Benutzer sowie andere wichtige
Dateien sichern müssen, die sonst während der Neuinstallation
verlorengehen würden. Viele Neulinge entscheiden sich für diese
Methode des Updates, weil es die einfachste ist. Tatsächlich ändert
sich aber von einer Version zur nächsten nicht viel, so daß eine
komplette Neuinstallation nicht notwendig ist und vermieden werden kann, wenn
man sich ein gewisses Know-how zum Thema Update aneignet.
Wir wollen Ihnen in diesem Abschnitt zeigen, wie Sie verschiedene einzelne
Teile Ihres Systems aktualisieren können. Wir werden besprechen, wie die
Systembibliotheken und Compiler auf den neuesten Stand gebracht werden, und
wir wollen auf eine angemessene Methode für die Installation neuer
Software eingehen. Im Abschnitt
»
Einen neuen Kernel erstellen
«
werden wir besprechen, wie Sie einen neuen Kernel erzeugen
können.
Die meisten der Programme auf einem Linux-System sind so kompiliert, daß
sie Shared Libraries benutzen. Diese Bibliotheken enthalten nützliche
Funktionen, die in vielen Programmen benötigt werden. Statt in jedem
Programm, das solche Funktionen aufruft, eine Kopie davon zu speichern, stehen
diese Funktionen in Systembibliotheken, auf die alle Programme zur Laufzeit
zugreifen können. Das bedeutet, daß bei der Abarbeitung eines
Programms zunächst der Programmcode selbst gelesen wird und dann die
entsprechenden Routinen aus den Shared Libraries. Dadurch läßt sich
eine Menge Speicherplatz sparen, weil nur eine Kopie der Library-Routinen auf
der Festplatte gespeichert werden muß.
Manchmal ist notwendig, Programme mit ihrer eigenen Kopie der Library-Routinen
zu kompilieren, statt die Routinen aus den Shared Libraries zu benutzen (beim
Debuggen eines Programms). Man sagt dann, daß solche Programme
statisch
gelinkt sind, während Programme, die die Shared Libraries benutzen,
dynamisch
gelinkt sind.
Dynamisch gebundene Programme sind also darauf angewiesen, daß die
Shared Libraries sich auf der Festplatte befinden. Shared Libraries sind so
geschrieben, daß die Programme, die diese Bibliotheken benutzen, in der
Regel nicht auf eine bestimmte Library-Version angewiesen sind. Das bedeutet,
daß Sie Ihre Libraries aktualisieren können und die Programme, die
auf diese Libraries zugreifen, werden dann automatisch die neuen Routinen
benutzen. (Es gibt eine Ausnahme: Wenn eine Bibliothek grundlegend
verändert wird, arbeiten die alten Programme nicht mit der neuen Version
zusammen. Sie erkennen das daran, daß sich die Versionsnummer vor dem
Punkt geändert hat -- mehr dazu erfahren Sie weiter unten. In einem
solchen Fall müssen Sie die alten und die neuen Bibliotheken auf der
Festplatte behalten. Alte Programme werden auf die alten Routinen zugreifen,
neue Programme benutzen die neuen Routinen.)
Wenn Sie ein Programm mit Shared Libraries kompilieren, wird dem
ausführbaren Programm ein Stück Code hinzugefügt, das beim
Start des Programms den dynamischen Linker
ld.so
aufruft.
ld.so
sucht die benötigten Shared Libraries und lädt die Routinen in den
Arbeitsspeicher. Dynamisch gebundene Programme enthalten auch sogenannte
»Stub«-Routinen, die im ausführbaren Programm als Platzhalter
für die eigentlichen Routinen aus den Shared Libraries dienen.
ld.so
ersetzt bei der Ausführung des Programms diese Stubs (etwa: Stummel)
durch den Library-Code.
Mit dem Befehl
ldd
können Sie die Shared Libraries anzeigen lassen, die ein bestimmtes
Programm benötigt. Ein Beispiel:
rutabaga% ldd /usr/bin/X11/xterm
libXaw.so.6 (DLL Jump 6.0) => /usr/X11R6/lib/libXaw.so.6.0
libXt.so.6 (DLL Jump 6.0) => /usr/X11R6/lib/libXt.so.6.0
libX11.so.6 (DLL Jump 6.0) => /usr/X11R6/lib/libX11.so.6.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26
Wie Sie sehen, greift das Programm
xterm
auf die vier Shared Libraries
libXaw
,
libXt
,
libX11
und
libc
zu. (Die ersten drei gehören zum X Window System, die letzte ist die
Standardbibliothek für C.) Es werden auch die Versionsnummern der
Bibliotheken angezeigt, für die dieses Programm kompiliert wurde (also
die Version der benutzten Stub-Routinen) sowie die Namen der Dateien, die die
Shared Libraries enthalten. Das sind diejenigen Dateien, die
ld.so
beim Programmstart finden wird.
Damit ein Programm eine Shared Library benutzen kann, muß die Version
der Stub-Routine (in der ausführbaren Datei) zur Version der Shared
Library kompatibel sein. Die Versionen werden als kompatibel betrachtet, wenn
die »große« Versionsnummer (major number) übereinstimmt.
Die große Versionsnummer ist der Teil vor dem ersten Punkt in der
Versionsangabe; in 6.0 ist die große Nummer also 6. Wenn ein Programm
mit der Version 6.0 der Stub-Routinen kompiliert wurde, kann das
ausführbare Programm die Shared Libraries der Versionen 6.1, 6.2 usw.
benutzen.
Im Abschnitt
»
Mehr Spaß mit Libraries
«
von
Kapitel 6,
Programmierung unter Linux
beschreiben wir, wie Sie in Ihren eigenen Programmen Shared Libraries benutzen
können.
Die Datei
/etc/ld.so.conf
enthält eine Liste der Verzeichnisse, die
ld.so
nach Shared Libraries durchsuchen wird. Hier ein Beispiel für eine solche
Datei:
/usr/lib
/usr/local/lib
/usr/X11R6/lib
ld.so
sucht immer in
/lib
und
/usr/lib
-- egal, was in
ld.so.conf
steht. In der Regel gibt es keinen Grund, diese Datei zu verändern, und
mit der Umgebungsvariable LD_LIBRARY_PATH können Sie diesem Suchpfad
weitere Verzeichnisse hinzufügen (wenn Sie z.B. Ihre eigenen Shared
Libraries benutzen, die nicht systemweit in Gebrauch sein sollen). Wenn Sie
doch weitere Einträge in
/etc/ld.so.conf
machen, sollten Sie auf jeden Fall den Befehl:
ldconfig
eingeben, der den Shared-Library-Cache aus dem Inhalt von
ld.so
neu erstellt. Dieser Cache wird von
ld.so
benutzt, um zur Laufzeit die Bibliotheken schnell finden zu können, ohne
tatsächlich die Verzeichnisse zu durchsuchen. In den Man-Pages zu
ld.so
und
ldconfig
finden Sie weitere Details hierzu.
Nachdem Sie jetzt erfahren haben, wie Shared Libraries funktionieren, wollen
wir sie auf den neuesten Stand bringen. Die beiden Bibliotheken, die am
häufigsten aktualisiert werden, sind
libc
(die Standard-C-Bibliothek) und
libm
(die Mathematik-Bibliothek).
(6)
Zu jeder Shared Library gehören drei Dateien:
-
bibliothek.a
-
Dies ist die statische Version der Bibliothek. Wenn ein Programm statisch
gebunden wird, werden Routinen aus dieser Datei direkt in das ausführbare
Programm kopiert, so daß das Programm seine eigene Kopie der
Library-Routinen enthält. Für statisch gebundene Programme werden
die beiden anderen Dateien aus dieser Bibliothek nicht mehr benötigt.
-
bibliothek.sa
-
Dies ist der Stub der Shared Library. Wenn ein Programm dynamisch gebunden
wird, wird für jede Routine der Bibliothek, auf die das Programm
zugreift, ein Stub aus dieser Datei in das ausführbare Programm kopiert.
Zur Laufzeit wird dieser Stub im Arbeitsspeicher durch die eigentliche Routine
aus der Shared Library ersetzt. Für dynamisch gebundene Programme wird
die Datei
bibliothek
.a
der Bibliothek nicht benutzt.
-
bibliothek.so.version
-
Dies ist das eigentliche Abbild (image) der Shared Library. Bei der
Ausführung eines dynamisch gebundenen Programms kopiert
ld.so
die Bibliotheks-Routinen aus dieser Datei in den Arbeitspeicher.
Die Bibliothek
libc
besteht aus den Dateien
libc.a
,
libc.sa
und
libc.so.4.5.26
. Die Dateien mit den Endungen
.a
und
.sa
stehen normalerweise in
/usr/lib
. Wenn Sie ein Programm kompilieren, wird entweder die
.a
- oder die
.sa
-Datei dazugebunden, und der Compiler sucht danach in
/usr/lib
. Wenn Sie eigene Bibliotheken benutzen, können diese Dateien an
beliebiger Stelle stehen; mit der Option
-L
bestimmen Sie, wo der Linker danach suchen soll. Im Abschnitt
»
Mehr Spaß mit Libraries
«
in
Kapitel 6
finden Sie Details hierzu.
Die meisten der Abbilder der Shared Libraries, auf die das gesamte System
zugreift, nämlich
bibliothek
.so.version
, stehen in
/lib
. Die Kopien der Shared Libraries können in einem beliebigen Verzeichnis
stehen, das
ld.so
zur Laufzeit durchsucht -- dazu gehören
/lib
,
/usr/lib
und die Dateien, die in
ld.so.conf
aufgelistet sind. In der Man-Page zu
ld.so
finden Sie Details hierzu.
Wenn Sie einen Blick in
/lib
werfen, werden Sie etwa folgendes sehen:
lrwxrwxrwx 1 root root 14 Oct 23 13:25 libc.so.4 ->libc.so.4.5.26
-rwxr-xr-x 1 root root 623620 Oct 23 13:24 libc.so.4.5.26
lrwxrwxrwx 1 root root 15 Oct 17 22:17 libvga.so.1 ->libvga.so.1.1.7
-rwxr-xr-x 1 root root 128004 Oct 17 22:17 libvga.so.1.1.7
In diesem Fall werden die Shared Library-Images für zwei Bibliotheken
angezeigt --
libc
und
libvga
. Beachten Sie, daß für jede Bibliothek ein symbolischer Link
namens
bibliothek
.so.major
angelegt wurde, wobei
major
die große Versionsnummer der Bibliothek ist. Die kleine Nummer (minor
number) wird ausgelassen, weil
ld.so
nur anhand der großen Nummer nach Bibliotheken sucht. Wenn
ld.so
ein Programm vorfindet, das mit den Stubs der Version 4.5.26 von
libc
kompiliert wurde, durchsucht es seinen Suchpfad nach der Datei
libc.so.4
. In diesem Fall ist
/lib/libc.so.4
ein symbolischer Link auf
/lib/libc.so.4.5.26
-- die aktuelle Library-Version, die wir tatsächlich installiert haben.
Wenn Sie eine Bibliothek aktualisieren, müssen Sie die Dateien auf
.a
,
.sa
und
.so.version
dieser Bibliothek ersetzen. Bei den ersten beiden ist das kein Problem:
Kopieren Sie einfach die neuen Versionen darüber. Beim Image der Shared
Library,
.so.version
, müssen Sie allerdings etwas vorsichtiger sein. Das liegt daran,
daß die meisten der Programme auf dem System diesen Code benutzen, so
daß man sie nicht einfach löschen oder umbenennen darf. Anders
gesagt: Der symbolische Link
bibliothek
.so.major
muß
immer
auf ein gültiges Library-Image verweisen. Zu diesem Zweck kopieren Sie
zunächst die neue Image-Datei nach
/lib
und ändern anschließend in einem Schritt mit
ln -sf
den symbolischen Link so, daß er auf die neue Datei verweist. Wir werden
das weiter unten vorführen.
Nehmen wir an, daß Sie von der Version 4.5.26 der
libc
auf die Version 4.6 updaten möchten. Sie sollten die Dateien
libc.a
,
libc.sa
und
libc.so.4.6
auf Ihrem System haben. Überschreiben Sie zuerst die alten Versionen,
indem Sie die neuen
.a
- und
.sa
-Dateien an die entsprechenden Stellen kopieren:
rutabaga# cp libc.a /usr/lib
rutabaga# cp libc.sa /usr/lib
Kopieren Sie dann die neue Image-Datei nach
/lib
(oder dahin, wo das neue Library-Image stehen soll):
rutabaga# cp libc.so.4.6 /lib
Mit dem Befehl
ls -l /lib/libc*
sollten Sie jetzt etwa folgendes angezeigt bekommen:
lrwxrwxrwx 1 root root 14 Oct 23 13:25 libc.so.4 ->libc.so.4.5.26
-rwxr-xr-x 1 root root 623620 Oct 23 13:24 libc.so.4.5.26
-rwxr-xr-x 1 root root 720310 Nov 16 11:02 libc.so.4.6
Damit der symbolische Link auf die neue Bibliothek verweist, geben Sie ein:
rutabaga# ln -sf /lib/libc.so.4.6 /lib/libc.so.4
Damit erhalten wir:
lrwxrwxrwx 1 root root 14 Oct 23 13:25 libc.so.4 ->/lib/libc.so.4.6
-rwxr-xr-x 1 root root 623620 Oct 23 13:24 libc.so.4.5.26
-rwxr-xr-x 1 root root 720310 Nov 16 11:02 libc.so.4.6
Jetzt können Sie ohne Bedenken die alte Image-Datei,
libc.so.4.5.26
, löschen. Der symbolische Link
muß
mit
ln -sf
in einem Schritt ersetzt werden -- insbesondere, wenn Sie Libraries wie z.B.
libc
aktualisieren.
Wenn Sie versuchen, zuerst den alten Link zu entfernen und dann mit
ln -s
den neuen hinzufügen möchten, ist es sehr wahrscheinlich, daß
ln
nicht mehr ausgeführt werden kann. Das liegt daran, daß der
symbolische Link bereits verschwunden ist und
ld.so
die Bibliothek
libc
nicht mehr finden kann. Sobald diese Bibliothek nicht mehr gefunden wird,
müssen Sie damit rechnen, daß die meisten Programme auf Ihrem
System nicht mehr ausgeführt werden können. Seien Sie also beim
Aktualisieren von Shared Library-Images sehr vorsichtig.
Es ist sicherlich keine schlechte Idee,
ldconfig
jedesmal aufzurufen, nachdem Sie Libraries aktualisiert oder hinzugefügt
haben, damit der Library-Cache, den
ld.so
benutzt, neu geschrieben wird. Es kann passieren, daß
ld.so
eine neue Library erst erkennt, nachdem Sie
ldconfig
aufgerufen haben.
Eine Frage bleibt noch zu beantworten: Wo bekommen Sie neue Versionen der
Bibliotheken? Einige der grundlegenden Systemlibraries (
libc
,
libm
usw.) können Sie aus dem Verzeichnis
/pub/Linux/GCC
auf sunsite.unc.edu auf Ihren Rechner herunterladen. Dieses Verzeichnis
enthält die Linux-Version des Compilers
gcc
, Libraries, Include-Dateien sowie andere Utilities. Zu jeder Datei sollte
eine
README
- oder
Release
-Datei gehören, die eine Installationsanweisung enthält. Andere
Bibliotheken werden an anderen Orten gepflegt und archiviert. Auf jeden Fall
sollte jede Library, die Sie installieren, aus den
.a
-,
.sa
- und
.so.version
-Dateien bestehen. Außerdem gehört ein Satz Include-Dateien
für den Compiler dazu.
Bei einem weiteren Bestandteil Ihres Systems ist es sehr wichtig, daß
Sie auf dem aktuellen Stand bleiben: dem C-Compiler mit den zugehörigen
Utilities. Dazu gehören
gcc
(der GNU-Compiler selbst für C und C++), der Linker, der Assembler, der
C-Präprozessor sowie verschiedene Include-Dateien und Libraries für
den Compiler. Diese sind alle in der
gcc
-Distribution für Linux enthalten. Normalerweise wird eine neue Version
des
gcc
zusammen mit den neuen Versionen von
libc
und den Include-Dateien veröffentlicht, die alle aufeinander angewiesen
sind.
Sie finden die aktuelle Version von
gcc
für Linux auf verschiedenen FTP-Servern -- u.a. auch in
/pub/Linux/GCC
auf sunsite.unc.edu. Aus den dazugehörigen Textdateien (release notes)
erfahren Sie, wie Sie vorgehen müssen. In der Regel wird eine neue
Version des Compilers eingespielt, indem man als root einige tar-Dateien
entpackt und eventuell ein paar andere Dateien löscht. Falls Sie keinen
Zugang zum Internet haben, können Sie den neuesten Compiler als Abzug
eines FTP-Servers in Form einer CD-ROM besorgen, wie wir das weiter oben
beschrieben haben.
Mit dem Befehl:
gcc -v
können Sie feststellen, welche Version von
gcc
Sie installiert haben. Die Anzeige sollte etwa so aussehen:
Reading specs from /usr/lib/gcc-lib/i486-linux/2.5.8/specs
gcc version 2.5.8
Beachten Sie, daß
gcc
selbst nur ein Steuerprogramm für den Compiler und die anderen
Programmierwerkzeuge unter:
/usr/lib/gcc-lib/rechner/version
ist.
gcc
(normalerweise in
/usr/bin
) kann mit Hilfe der Option
-V
für viele Versionen des eigentlichen Compilers benutzt werden. Im
Abschnitt
»
Programmieren mit gcc
«
in
Kapitel 6
gehen wir im Detail auf die Arbeit mit
gcc
ein.
Natürlich werden Sie gelegentlich auch andere Teile Ihres Systems auf den
neuesten Stand bringen müssen. Wir haben bereits erwähnt, daß
die einfachste und beste Vorgehensweise die ist, daß Sie nur dann
updaten, wenn es wirklich notwendig ist. Warum sollten Sie beispielsweise
immer die neueste Version von Emacs auf Ihrem System haben, wenn Sie das
Programm gar nicht benutzen? Eigentlich besteht auch kein Grund, bei
regelmäßig benutzten Anwendungen immer auf dem aktuellen Stand zu
bleiben -- wenn Sie mit Ihrer Version zufrieden sind, besteht kaum
Veranlassung zum Update.
Wenn Sie andere Anwendungsprogramme aktualisieren möchten, müssen
Sie die neueste Version der Software besorgen. In der Regel sind das mit
gzip
oder
compress
gepackte Dateien. Solche Programmpakete werden in verschiedenen Formaten
verteilt; dazu gehören
binäre Dateien
, bei denen der Binärcode und dazugehörige Dateien so archiviert
sind, daß sie auf Ihrem System sofort entpackt werden können. Ein
anderes Format enthält
Quellcode
(oder Teile des Quellcodes), so daß Sie einige Befehle ausführen
müssen, um die Programme zu kompilieren und auf Ihrem System zu
installieren.
Die Shared Libraries machen es sehr einfach, Software in Form von
Binärdateien zu verteilen; solange Sie eine Version der Libraries haben,
die zu den Stubs in der Software kompatibel ist, werden Sie keine Probleme
haben. Allerdings ist es oft einfacher (und vorteilhafter), ein Programm in
Form von Quellcode zu verteilen. Das bietet Ihnen einerseits die
Möglichkeit, den Code anzuschauen und weiterzuentwickeln; andererseits
haben Sie dann die Gelegenheit, das Programm speziell für Ihr System und
mit eigenen Libraries zu kompilieren. Viele Programme erlauben bei der
Kompilierung die Angabe gewisser Optionen, etwa das selektive Einbinden
bestimmter Programmteile in das fertige Programm. Diese Art der Anpassung ist
nicht möglich, wenn Sie fertig kompilierten Binärcode erhalten.
Auch die Systemsicherheit kommt ins Spiel, wenn binäre Dateien ohne
Quellcode installiert werden. Obwohl man auf UNIX-Systemen kaum von
Computerviren gehört hat,
(7)
ist es nicht so schwierig, ein »Trojanisches Pferd« zu entwickeln
-- ein Programm, das anscheinend eine nützliche Funktion ausführt,
in Wirklichkeit aber Schaden im System verursacht. So könnte jemand z.B.
ein Programm schreiben, das als »Zugabe« alle Dateien im
Home-Verzeichnis desjenigen löscht, der das Programm aufruft. Weil ein
solches Programm mit den Berechtigungen des Benutzers ausgeführt wird,
hat es auch die Möglichkeit, auf diese Art Schaden anzurichten.
(Selbstverständlich verhindern die Sicherheitsmechanismen von UNIX,
daß auch an den Dateien weiterer Benutzer oder an wichtigen
Systemdateien, die root gehören, Schaden entstehen kann.)
Obwohl das Installieren von Quellcode so etwas nicht unbedingt verhindern kann
(lesen Sie die Quelldateien aller Programme, die Sie für Ihr System
kompilieren?), haben Sie auf jeden Fall die Möglichkeit nachzuschauen,
was das Programm tatsächlich tut. Ein Programmierer müßte sich
einige Mühe geben, um ein solches Trojanisches Pferd zu verstecken --
wenn Sie aber völlig unbedarft binären Code installieren, setzen Sie
sich selbst der Gefahr aus.
Auf jeden Fall ist der Umgang mit Quellcode und binären Dateien recht
einfach. Wenn das Programmpaket als tar-Datei verteilt wird, finden Sie
zunächst mit
tar t
heraus, wie die Dateien archiviert wurden. Falls es sich um Binärdateien
handelt, können Sie die Dateien wahrscheinlich von
/
oder
/usr
aus sofort entpacken. Zuvor sollten Sie alle alten Versionen des Programms
sowie die dazugehörigen Dateien löschen (alle die, die nicht von der
neuen tar-Datei überschrieben werden). Wenn die alte ausführbare
Datei in Ihrem Suchpfad vor der neuen Version steht, werden Sie weiterhin mit
dem alten Programm arbeiten, solange Sie dieses nicht entfernt haben.
Der Umgang mit Quellcode ist nicht ganz so einfach. Als erstes müssen Sie
die Quelldateien in einem eigenen Verzeichnis entpacken. Auf den meisten
Systemen ist das
/usr/src
. Normalerweise brauchen Sie keine root-Berechtigung, um ein Softwarepaket zu
kompilieren (aber Sie werden in der Regel als root das fertig kompilierte
Programm installieren!). Deshalb ist es vielleicht eine gute Idee, mit dem
Befehl:
chmod 1777 /usr/src
das Verzeichnis
/usr/src
für alle Benutzer beschreibbar zu machen. Danach steht es jedem Benutzer
frei, Unterverzeichnisse zu
/usr/src
anzulegen, um dort Dateien zu installieren. Die 1 an der ersten Stelle der
Modusbits ist das »Sticky«-Bit; dieses verhindert, daß
Benutzer sich gegenseitig die Unterverzeichnisse löschen.
Sie können dann ein Unterverzeichnis in
/usr/src
anlegen und die tar-Datei dort entpacken, oder Sie entpacken direkt von
/usr/src
aus, wenn das Archiv bereits ein Unterverzeichnis enthält.
Sobald die Quelldateien entpackt sind, sollten Sie als nächstes die
README
-Dateien und Installationshinweise lesen, die zu den Quellen gehören.
Fast alle Pakete werden mit solcher Dokumentation verteilt. Grundsätzlich
gehen Sie zum Kompilieren der meisten Programme wie folgt vor:
-
Schauen Sie sich das
Makefile
an. Diese Datei enthält Anweisungen für
make
, das die Arbeit des Compilers während der Kompilierung steuert. Bei
vielen Anwendungen werden Sie im
Makefile
kleinere Anpassungen an Ihr System vornehmen müssen; das sollte leicht
herauszufinden sein. In den Installationshinweisen werden Sie erfahren, ob
dies notwendig ist. Falls Sie weitere Hilfestellung zum
Makefile
brauchen, lesen Sie den Abschnitt
»
Die Makefiles
«
in
Kapitel 6
.
-
Editieren Sie ggf. weitere Dateien, die zum Programm gehören. Einige
Anwendungen erwarten, daß Sie eine Datei namens
config.h
anpassen; auch dies sollte in den Installationshinweisen erwähnt werden.
-
Rufen Sie ggf. ein Konfigurationsskript auf. Ein solches Skript stellt fest,
wie Ihre Systemumgebung zusammengesetzt ist -- dies wird bei komplexeren
Anwendungen nötig sein. Sie werden selbst herausfinden, wann Sie diesen
Schritt machen müssen.
-
Rufen Sie
make
auf. In der Regel werden daraufhin die notwendigen Schritte zur Kompilierung
ausgeführt, wie sie im Makefile definiert sind. Oft müssen Sie
make
noch ein »Ziel« (target) mitgeben, etwa
make all
oder
make install
. Dies sind zwei häufig benutzte Ziele;
make all
wird meistens nicht benötigt, kann aber eingesetzt werden, um alle Ziele
einzuschließen, die im Makefile aufgeführt sind (z.B. um alle
Programme in einem Paket zu kompilieren, wenn per Voreinstellung nur eines
kompiliert wird). Mit
make install
werden nach der Kompilierung sowohl der ausführbare Code als auch alle
dazugehörigen Dateien auf dem System installiert. Aus diesem Grunde wird
make install
normalerweise als root aufgerufen.
Es kann passieren, daß Sie bei der Kompilierung oder Installation neuer
Software in Ihrem System auf Schwierigkeiten stoßen. Dies gilt
insbesondere dann, wenn das betreffende Programm unter Linux noch nicht
getestet wurde oder wenn es von anderen Programmen abhängt, die Sie nicht
installiert haben. In
Kapitel 6,
Programmierung unter Linux
besprechen wir den Compiler,
make
und dazugehörige Tools im Detail.
Die meisten Softwarepakete enthalten neben den Quelltexten und
ausführbarem Code auch Man-Pages und andere Dateien. Das
Installationsskript (falls vorhanden) wird diese Dateien an einer geeigneten
Stelle abspeichern. Die Manual-Pages haben Namen wie z.B.
foobar.1
oder
foobar.man
. Diese Dateien sind (meistens)
nroff
-Quelltexte und werden von
man
in ein lesbares Format gebracht. Wenn der Quelltext einer Man-Page eine Ziffer
als Suffix aufweist, etwa
.1
, sollten Sie diese Datei in das Verzeichnis
/usr/man/man1
kopieren, wobei die
1
mit der Ziffer im Suffix übereinstimmt. (Diese Ziffer entspricht der
Nummer des »Abschnitts« (section), in den diese Man-Page
gehört; für die meisten Anwenderprogramme ist das die 1.) Bei
Dateien mit dem Suffix
.man
wird es in der Regel ausreichen, wenn Sie die Datei nach
/usr/man/man1
kopieren und dabei die Erweiterung
.man
in
.1
umbenennen.
Fußnoten
-
(6)
-
Zum Zeitpunkt des Schreibens findet in der Linux-Gemeinde ein Umschwung in
Richtung auf ELF statt ein anderes Dateiformat für ausführbare
Programme und Shared Libraries. ELF wird sich auf einen Teil des Materials in
diesem Abschnitt auswirken z.B. wird die Bibliothek libm eventuell nicht mehr
»Shared« sein. Trotzdem sollte fast alles, was wir hier besprechen,
auch unter ELF gültig sein.
-
(7)
-
Ein »Virus« im klassischen Sinn ist ein Programm, das sich an einen
»Wirt« anhängt und dann aktiv wird, wenn das Wirtsprogramm
aufgerufen wird. Auf UNIX-Systemen braucht man in der Regel
Root-Berechtigungen, um wirklich Schaden anzurichten; wenn ein Programmierer
aber weiß, wie er sich diese Berechtigungen verschaffen kann, wird er
sich kaum noch mit einem Virus abgeben.
Inhaltsverzeichnis 
Vorherige
Abschnitt 
Nächste Abschnitt