Docs/Basic tasks/Installing and removing software/Installing from source

Aus Mandriva Community Wiki

Wechseln zu: Navigation, Suche
Installation von Software aus dem Quellcode unter Mandriva Linux

Die Installation von Software durch eine Kompilierung aus dem Quellcode ist die am wenigsten empfohlene Installationsmethode unter Mandriva Linux und sollte nur verwendet werden, wenn du die benötigte Software in keinem der offiziellen Mandriva Software-Repositories und keinem der Repositories von Drittanbietern findest (weitere Einzelheiten zu anderen Software-Installationsmethoden findest du hier). Manchmal ist eine Installation aus dem Quellcode jedoch unumgänglich. Auf dieser Seite wird die allgemeine Vorgehensweise zum Installieren von Software durch eine Kompilierung des Quellcodes unter Mandriva Linux erläutert.

Inhaltsverzeichnis

[bearbeiten] Bevor du loslegst

Bevor du loslegst, solltest du dir einen allgemeinen Überblick darüber verschaffen, worum es bei der Kompilierung von Software aus dem Quellcode geht, und einige vorbereitende Arbeiten erledigen.

[bearbeiten] Was geschieht?

Wenn du Software aus dem Quellcode installierst, werden in der Regel drei Schritte nacheinander abgearbeitet. Im ersten Schritt analysiert ein Script dein System; es prüft, ob sämtliche für die Kompilierung benötigte Software installiert ist, und konfiguriert gegebenenfalls bestimte optionale Aspekte des Kompiliervorgangs. Im zweiten Schritt findet die eigentliche Kompilierung statt. Im dritten Schritt werden die kompilierte Anwendung, die Bibliotheken und die unterstützenden Zusatzdateien in die jeweiligen Verzeichnisse auf deinem System kopiert, damit alle Benutzer darauf zugreifen können. Bei sehr einfach gehaltener Software entfällt zuweilen der erste Schritt; manche Anwendungen sind so konzipiert, dass sie ohne den dritten Schritt genutzt werden können.

[bearbeiten] Vorbereitung

Es ist wichtig, den Quellcode auch nach einer erfolgreichen Installation der Anwendung verfügbar zu haben, da es ohne den Quellcode sehr schwierig ist, die Anwendung zu deinstallieren. Daher empfiehlt es sich, den Quellcode ordentlich organisiert aufzubewahren. Es ist ratsam, ein Verzeichnis namens source oder src in deinem Heimatverzeichnis zu erstellen und den Quellcode aller Anwendungen, die du kompilierst, in Unterverzeichnissen dieses Verzeichnisses zu organisieren. Außerdem musst du sicherstellen, dass einige grundlegende Anwendungen, die für fast jede Softwarekompilierung benötigt werden, auf deinem Rechner installiert sind. Bevor du versuchst, eine Anwendung zu kompilieren, solltest du immer die im Archiv beiliegende Dokumentation durchlesen. Oft findest du dort eine Datei namens INSTALL, die spezifische Installationsanweisungen sowie Hinweise zu der Anwendung enthält.

[bearbeiten] 1. Schritt

Bei den meisten Anwendungen wird als 1. Schritt das Script ./configure auf der obersten Ebene des Quellcode-Verzeichnisses ausgeführt. Sofern der Konfigurationsvorgang erfolgreich abgeschlossen wird, wird das Script entweder ohne Fehlermeldung oder mit einer Zusammenfassung der exakten weiteren Vorgehensweise bei der Kompilierung (d. h. welche Optionen aktiviert werden und wohin die Software installiert wird) beendet. In komplexeren, ausgereiften Softwarepaketen sind üblicherweise mehrere optionale Parameter für den configure-Befehl vorgesehen, die dazu genutzt werden können, bestimmte Funktionen der Software ein- bzw. auszuschalten. Du kannst den Befehl ./configure --help verwenden, um diese optionalen Parameter anzuzeigen und zu prüfen, ob sie für dich von Interesse sind. In den meisten Fällen sollten die Optionen --prefix, --sysconfdir und --localstatedir nicht verwendet werden.

[bearbeiten] Varianten

Wie bereits weiter oben angedeutet, entfällt bei manchen einfachen Anwendungen der ./configure-Schritt vollständig. In diesem Fall kannst du sofort zum #2. Schritt übergehen. In manchen anderen Fällen - in der Regel nur für unausgereifte Software oder für instabile Snapshots - musst du einen weiteren Befehl eingeben, bevor ./configure gestartet wird, nämlich ./autogen.sh. Hierdurch werden das configure-Script sowie die Dateien, die zur Erzeugung der so genannten Makefiles (dies sind die Scripte, welche die eigentliche Kompilierung steuern) benötigt werden, angelegt. In Ausnahmefällen greifen Anwendungen auf ein vollständig anderes Kompilierungssystem als das hier dargelegte zurück. In diesem Fall wird die Vorgehensweise mit an Sicherheit grenzender Wahrscheinlichkeit in einer README- oder INSTALL-Datei erläutert, die dem Quellcode beiliegt.

[bearbeiten] Probleme

Es ist durchaus üblich, dass in diesem Schritt Probleme auftreten, insbesondere die ersten Male, wenn du Software aus dem Quellcode zu installieren versuchst. Das configure-Script wird mit einem Fehler beendet, der besagt, dass ein benötigtes Paket oder eine benötigte Bibliothek nicht installiert ist. Häufig wirst du dabei aber feststellen, dass das monierte Paket allerdings bereits installiert ist.

Keine Panik! Dieser Fehler ist auf eine Konvention in der Mandriva-Paketerstellung zurückzuführen. In Mandriva Linux werden gemeinsam genutzte Bibliotheken - d. h. Sammlungen von Funktionen, die in gemeinsam genutzten Verzeichnissen abgelegt sind und möglicherweise von mehr als einer Anwendung verwendet werden - in von Anwendungen getrennten Paketen untergebracht. Diese Bibliothek-Pakete werden dann noch weiter aufgeteilt. Manche Bibliotheken sind ausschließlich zu Kompilierungszwecken von Nutzen: sie werden niemals für die einfache Nutzung einer Anwendung benötigt. In Mandriva Linux befinden sich die Bibliotheken, die zur Nutzung einer Anwendung benötigt werden, in einem Paket, während die zur Kompilierung benötigten Bibliotheken in einem anderen Paket liegen. Daher bietet Mandriva Linux für den üblichen Fall, dass eine Anwendung mit einer eigenen Bibliothek daherkommt, normalerweise drei Pakete. Beispiel: Für eine Anwendung namens 'beispiel' sind i. d. R. die folgenden drei Pakete verfügbar:

beispiel libbeispiel libbeispiel-devel

Gegebenenfalls wird in der Bezeichnung von einem, zwei oder allen drei Paketen eine Versionsnummer angegeben; das grundlegende Muster zur Bezeichnung der Pakete bleibt jedoch im Allgemeinen erhalten. Das Paket 'beispiel' enthält die eigentliche Anwendung, die Konfigurationsdateien, Menüeinträge und mit der Anwendung verbundene Daten wie Klänge, Grafiken, Übersetzungen usw. Das Paket 'libbeispiel' enthält die Dateien der Bibliothek, die mit der Anwendung verknüpft ist; diese Dateien dienen zum Ausführen der Anwendung (und aller Anwendungen, die auf dieselbe Bibliothek zurückgreifen möchten). Das Paket 'libexample-devel' enthält die Dateien für die mit der Anwendung verknüpfte Bibliothek, die nur zum Kompilieren von Anwendungen, die auf diese Bibliothek zurückgreifen, von Nutzen sind.

Falls du versucht hast, ein Programm aus dem Quellcode zu installieren, und falls das configure-Script mit der Fehlermeldung beendet wurde, dass 'example' nicht installiert ist, musst du wahrscheinlich zunächst das Paket libexample-devel installieren.

Häufig (während der ersten Installationsversuche aus Quellcode) werden noch einige -devel-Pakete benötigt, die noch nicht installiert sind, so dass das configure-Script nach der Installation eines benötigten -devel-Pakets erneut fehlschlägt und sich darüber beschwert, dass ein weiteres Paket fehlt. Nicht aufgeben - installiere einfach nacheinander sämtliche benötigten -devel-Pakete, um diesen Schritt schließlich erfolgreich abzuschließen!

[bearbeiten] 2. Schritt

Nachdem du den 1. Schritt erfolgreich erledigt hast, geht es nun frischen Mutes an den 2. Schritt - die Kompilierung. Dieser Schritt wird normalerweise durch den Befehl make auf der obersten Ebene des Quellcodes gestartet. In ordentlich geschriebenen Anwendungen sollte dieser Schritt ohne Probleme abgeschlossen werden, sofern das configure-Script erfolgreich beendet wurde. In diesem Fall dauert der Vorgang eine gewisse Zeit (je nach Komplexität der Anwendung und Rechenleistung deines PC benötigt die Kompilierung einige Sekunden bis hin zu mehreren Stunden) und wird dann mit einer kurzen, abschließenden Mitteilung beendet: solange keine Fehlermeldung angezeigt wird, war die Kompilierung erfolgreich.

[bearbeiten] Probleme

Viele Anwendungen sind nicht absolut sauber geschrieben; so kann es vorkommen, dass die Entwickler vergessen haben, in das configure-Script eine Prüfung einzubauen, ob eine bestimmte Bibliothek, die für die Kompilierung benötigt wird, tatsächlich vorhanden ist. In diesem Fall wird der Kompiliervorgang plötzlich mit mehreren Fehlermeldungen abgebrochen. Um herauszufinden, was schief gegangen ist, solltest du zunächst einen Blick auf die erste Fehlermeldung werfen. Häufig besagt diese Fehlermeldung, dass -lIRGENDWAS nicht gefunden wurde. Dies bedeutet, dass eine benötigte Entwicklungsbibliothek nicht installiert worden ist (vgl. 1. Schritt). Üblicherweise ähnelt die Bezeichnung IRGENDWAS dem Namen des benötigten Pakets, aber manchmal kann dies recht schwer zu entschlüsseln sein. Falls du nicht weiterkommst, kannst du per Google nach der Fehlermeldung suchen oder in einem Mandriva-Hilfeforum (beispielsweise in den Mandriva-Foren oder auf der Website der Anwendung, die du zu kompilieren versuchst, nach Hilfe Ausschau halten. Ein Blick auf die Dateien README und INSTALL im Quellcode kann sich lohnen - manchmal sind darin die benötigten Pakete angegeben. Installiere das entsprechende Paket und starte erneut den Befehl make, der nun mehr oder weniger an der Stelle fortgesetzt werden sollte, an der zuvor die Fehlermeldung erschienen ist. Es ist nicht erforderlich, den gesamten Vorgang ab dem 1. Schritt neu zu starten.

Falls der Kompiliervorgang mit einem anderen Fehlertyp abbricht, benötigst du in der Regel Hilfe von einem Fachmann in einem Mandriva-Hilfeforum oder auf der Website der Anwendung, die du installieren möchtest.

[bearbeiten] Varianten

Abweichende Vorgehensweisen sind in diesem Schritt nur selten anzutreffen. Hin und wieder muss der Befehl make mit zusätzlichen Parametern gestartet werden, um optionale Teile der Anwendung zu kompilieren, oder der Befehl muss erneut in einem Unterverzeichnis ausgeführt werden. Derlei Anforderungen werden jedoch fast immer in der README- oder INSTALL-Datei erläutert.

[bearbeiten] 3. Schritt

Wenn der 2. Schritt erfolgreich beendet wurde, kannst du die Anwendung nun installieren. Hierzu werden die fertig kompilierten Dateien in die Verzeichnisse kopieren, in denen sie allen Benutzern zur Verfügung stehen; die gemeinsam genutzten Dateien (sofern vorhanden) sind nun auch für andere Anwendungen verfügbar. Dieser Schritt wird normalerweise erledigt, indem der Befehl make install mit root-Rechten ausgeführt wird (um zum Administrator root zu werden, musst du in einer Konsole den Befehl su ausführen und das root-Kennwort eingeben. Nicht vergessen, nach dem Befehl make install die root-Shell mit exit zu beenden).

In den meisten Fällen wird die Anwendung in das Verzeichnis /usr/local installiert. Die ausführbare(n) Datei(en) wird/werden im Verzeichnis /usr/local/bin abgelegt, Bibliotheken in /usr/local/lib, Konfigurationsdateien in /usr/local/etc und andere Dateien in /usr/local/share. Dies ist eine sinnvolle und nützliche Konvention: Mandriva Linux (and alle anderen Distributionen) installieren niemals etwas in /usr/local und befassen sich nicht mit Dateien in diesem Verzeichnis; du kannst also mit großer Gewissheit davon ausgehen, dass alle Dateien in diesem Verzeichnis dort entweder dadurch, dass du eine Anwendung aus Quellcode kompiliert und installiert hast, oder infolge eines von dir manuell ausgeführten Befehls dort abgelegt wurden. Wenn du diese Konvention beachtest, kann kein Programm, das du aus Quellcode installiert hast, unentwirrbar mit Teilen des von den Mandriva-Paketwerkzeugen installierten Systems verflochten werden.

[bearbeiten] Varianten

Gelegentlich triffst du vielleicht auf eine Anwendung, die sich standarmäßig in die Systemverzeichnisse installieren möchte: /usr/bin für ausführbare Dateien, /usr/lib für Bibliotheken, /etc für Konfigurationsdateien und so weiter. Dies gilt als äußerst schlechtes Benehmen, da es dazu führen kann, dass Anwendungen, die aus Quellcode kompiliert wurden, auf verwirrende und möglicherweise schädliche Weise mit Anwendungen verflochten werden, die von den Mandriva-Paketwerkzeugen installiert wurden. Ein solches Verhalten ist als ernsthafter Fehler der Anwendung anzusehen (sofern es nicht absolut unabdingbar ist, dass die Anwendung in die Systemverzeichnisse installiert werden muss, um funktionieren zu können) und sollte den Entwicklern der Anwendung als Fehler gemeldet werden.

[bearbeiten] Probleme

Probleme bei der Ausführung dieses Schritts sind sehr ungewöhnlich: falls ein Fehler auftritt, musst du dich um die Hilfe eines Fachmanns bemühen. Wesentlich üblicher ist es, dass eine Anwendung, die gemäß diesem Verfahren installiert wurde, nicht gestartet werden kann. Dies liegt daran, dass die Mandriva Linux-Umgebung Anwendungen, die im Verzeichnis /usr/local installiert wurden, nicht berücksichtigt.

[bearbeiten] Befehl nicht gefunden - command not found

Wenn beim Versuch, die Anwendung mit dem korrekten Befehl zu starten, die Fehlermeldung 'command not found' ausgegeben wird, solltest du zunächst den Befehl hash -r ausführen und es dann erneut versuchen. Wird das Problem hierdurch nicht behoben, befindet sich das Verzeichnis /usr/local/bin ggf. nicht in deinem Suchpfad (PATH). PATH ist eine Umgebungsvariable, welche die Namen von Verzeichnissen enthält, in denen ausführbare Dateien abgelegt sind: Jede ausführbare Datei in einem in der PATH-Variablen angegebenen Verzeichnis kann durch einfache Eingabe ihres Namens ausgeführt werden, ohne Angabe des Verzeichnisses, in dem sich die Datei befindet. Um das Verzeichnis /usr/local/bin einmalig zu deinem Suchpfad PATH hinzuzufügen, ist der Befehl export PATH=$PATH:/usr/local/bin auszuführen. Um sicherzustellen, dass /usr/local/bin bei jedem Systemstart zum PATH hinzugefügt wird, kannst du die Datei ~/.bash_profile bearbeiten. Falls darin eine Zeile wie:

PATH=$PATH:$HOME/bin

vorhanden ist, kannst du einfach /usr/local/bin an das Ende dieser Zeile anhängen:

PATH=$PATH:$HOME/bin:/usr/local/bin

Falls keine solche Zeile vorhanden ist, fügst du die folgenden zwei Zeilen ein:

PATH=$PATH:/usr/local/bin
export PATH

Nach allen Änderungen der Umgebungsvariable PATH solltest du den Befehl hash -r ausführen.

[bearbeiten] Bibliotheken nicht gefunden - libraries not found

Falls du die Anwendung starten kannst, diese aber abstürzt und meldet, dass sie Bibliothekdateien (libraries) nicht finden kann, musst du das Verzeichnis /usr/local/lib zu der Liste der Verzeichnisse hinzufügen, in denen das System nach gemeinsam genutzten Bibliotheken sucht. Hierzu bearbeitest du die Datei /etc/ld.so.conf - hierzu sind root-Rechte erforderlich - und fügst die folgende Zeile am Ende der Datei hinzu:

/usr/local/lib

Speichere die Datei und führe - immer noch mit root-Rechten - den Befehl ldconfig aus. Dies braucht nur ein einziges Mal erledigt zu werden.

[bearbeiten] Probleme mit pkgconfig

Hin und wieder kannst du ein weiteres, ziemlich undurchsichtiges Problem antreffen. Manche Anwendungen - im Allgemeinen GNOME-Anwendungen - greifen auf ein System namens pkgconfig zurück. Dies wird bei der Kompilierung von Anwendungen als standardisiertes Verfahren für die Prüfung, ob die benötigten Entwicklungsdateien einer anderen Anwendung vorhanden sind, verwendet. Wenn du eine Anwendung oder Bibliothek aus Quellcode installierst, die auf das pkgconfig-System zurückgreift, um anderen Anwendungen mitzuteilen, dass sie für Kompilierungszwecke zur Verfügung steht, installiert diese Anwendung oder Bibliothek eine Datei namens programname.pc in das Verzeichnis /usr/local/lib/pkgconfig. Versuchst du nun, eine weitere Anwendung zu kompilieren, die sich darauf verlässt, dass die erste Anwendung vorhanden ist, beschwert sich diese zweite Anwendung möglicherweise darüber, dass sie die erste Anwendung nicht finden kann. Dies liegt daran, dass das Verzeichnis /usr/local/lib/pkgconfig von pkgconfig auf der Suche nach verfügbaren Bibliotheken nicht berücksichtigt wird. Um dieses Problem einmalig zu beheben, führst du den Befehl export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig aus. Um das Problem permanent zu beheben, fügst du die folgenden zwei Zeilen zur Datei ~/.bash_profile hinzu:

PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH

[bearbeiten] Deinstallation

Zur Deinstallation von Software, die du aus Quellcode kompiliert hast, brauchst du im Allgemeinen lediglich mit root-Rechten den Befehl make uninstall auf der obersten Ebene des Quellcode-Verzeichnisses auszuführen. In seltenen Fällen kannst du Pech haben - nämlich dann, wenn in der Software zwar make install, nicht aber make uninstall implementiert ist. Dies gilt als äußerst schlechtes Benehmen und sollte den Entwicklern der Software als Fehler der höchsten Dringlichkeitsstufe gemeldet werden. In diesem Fall besteht die einzige Möglichkeit, die Software zu deinstallieren, darin, manuell alle von der Software installierten Dateien aufzuspüren und zu löschen. Wie weiter oben dargelegt, liegen die Dateien wahrscheinlich alle in der Verzeichnishierarchie unter /usr/local.

Falls du eine Anwendung aus Quellcode kompiliert hast, den Quellcode verloren hast und die Anwendung dann deinstallieren möchtest, bieten sich dir zwei Möglichkeiten. Du kannst die Dateien manuell aufspüren und löschen (wie bei Anwendungen, in denen make uninstall nicht implementiert ist). Es gibt allerings einen nützlichen Trick, mit dem dir diese Detektivarbeit in den meisten Fällen erspart bleibt. Du kannst einfach dieselbe Version des Quellcodes neu herunterladen, den 1. und den 2. Schritt wie bei der ersten Installation der Anwendung ausführen und dann mit root-Rechten den Befehl make uninstall ausführen.

[bearbeiten] Fortgeschrittene Themen: Installation in Systemverzeichnisse

Zuweilen begegnet man einer Anwendung, die nicht korrekt funktioniert, falls sie nicht in die Systemverzeichnisse installiert wird - mit anderen Worten: die Anwendung kann nicht in /usr/local installiert werden und dabei korrekt funktionieren. Dies wird normalerweise in der Datei INSTALL oder README angegeben. In diesem Fall musst du das ./configure-Script mit einigen Parametern starten, um dem Script mitzuteilen, wohin die Dateien der Anwendung zu installieren sind. An dieser Stelle empfiehlt sich größte Vorsicht, damit kein Konflikt zwischen der aus dem Quellcode installierten Anwendung und einer Anwendungsversion, die aus einem Mandriva-Paket installiert wurde, entsteht! Falls du eine Anwendung auf diese Weise aus dem Quellcode installieren möchtest, solltest du zunächst sicherstellen, dass jedwede aus Mandriva-Paketen installierte Version entfernt worden ist. Wenn du eine Anwendung aus dem Quellcode installiert hast, solltest du keine Version derselben Anwendung aus fertigen Paketen installieren, bevor du die aus dem Quellcode kompilierte Anwendung vollständig entfernt hast. Von einer Installation einer aktualisierten Version einer gemeinsam genutzten Bibliothek auf diese Weise ist fast in allen Fällen abzuraten, da andere Software im System vermutlich mit der aktualisierten Bibliothek nicht mehr korrekt funktioniert.

Um eine Anwendung in die Systemverzeichnisse zu installieren, führst du den folgenden configure-Befehl aus: ./configure --prefix=usr --sysconfdir=/etc --localstatedir=/var.

[bearbeiten] Fortgeschrittene Themen: Erzeugen von RPM-Paketen

Wenn du immer wieder Software aus Quellcode kompilierst, magst du die Software vielleicht in RPM-Paketen verpacken, statt sie direkt zu installieren - entweder für deinen eigenen Komfort bei der Installation, Deinstallation und Überwachung der Softwareversionen oder als Beitrag zu den Mandriva-Paketquellen. Bei Interesse an dieser Arbeit solltest du bitte die in diesem Wiki vorhandene Dokumentation zum Thema RPM-Paketbau lesen. Eine gute erste Anlaufstelle ist das RPM Howto.

Persönliche Werkzeuge
Andere Sprachen