Tutorials - Installation von Software aus Quellarchiven unter Linux

Sprachenübersicht/Betriebssysteme/Linux

Installation von Software aus Quellarchiven unter Linux

Diese Seite wurde 6476 mal aufgerufen.

Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.

Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: Installieren, Linux, entpacken, deinstallieren, tarball, deinstall, sourcecode, quellcode

Inhaltsverzeichnis

• Vorwort
  
• Zu dieser FAQ
  
• Allgemein
  
• Entpacken der Archive
  
• Installation
  
• Deinstallation
  
• Troubleshooting
  
• Fehlermeldungen bei make
  
• Dokumentation, Quellen und Hilfe
  
• Autor
  
• Lizenz
  

Vorwort Top

Quelle: howto.linux-hardware-shop.de/software.htm

Ulrich Ivens ?howto@linux-hardware-shop.de?
Version: 1.5
Datum: 31.05.2003

Zu dieser FAQ Top

Diese FAQ soll die Installation von Software unter Linux aus Quellarchiven, so genannten "Tarballs" verdeutlichen. Sie soll grundsätzliche Hilfe zu Problemen und Fehlermeldungen geben und verdeutlichen wie die Konfiguration und Installation von Software aus Quellcode funktioniert. Primär angesprochen werden Linuxneulinge und noch nicht so erfahrene Linux - Anwender. Aber auch alte Hasen könnten hier evtl. noch den ein oder anderen Tip finden

Allgemein Top

Quellarchive liegen in der Regel als folgende Dateitypen vor, je nachdem welcher Packalgorithmus vom Verfasser des Paketes verwendet wurde.

• tar (unkomprimiert)

• tar.Z

• tar.gz oder tgz, was das selbe ist

• tar.bz2

In Tarballs steht der reine Quellcode welchen man mit den entsprechenden Kenntnissen der jeweiligen Programmiersprache leicht verifizieren kann oder bei Bedarf und entsprechender Lizenz unter der die Software veröffentlicht wurde ändern / erweitern kann. Der gleiche Tarball kann auf verschiedenen UNIX - Derivaten compiliert werden. Dadurch wird der Autor der Software davor bewahrt, verschiedene Versionen zu schreiben.

Entpacken der Archive Top

Bevor man irgendwas machen kann muss man das Quellarchive erst mal entpacken. Das kann man mit Linux - Bordmitteln leicht erledigen. Die folgenden Beispiele verdeutlichen für ein unkomprimiertes tar-Archiv und die jeweiligen Packalgorithmen die Vorgehensweise auf der Shell:

Es kann auch sein das tar nicht mit bz2 Archiven arbeiten kann (bei älteren Linux Distributionen und anderen UNIX - Derivaten, die nicht über GNU/tar verfügen, bzw. wo der Distributor tar nicht gepatcht hat). Dann hat man z.B. diese Möglickkeiten die Archive über so genannte Pipelines(1) zu entpacken:

Informationen zu tar, gzip und bzip2 findet man in der entsprechenden manpage die man sich unbedingt zu Gemüte führen sollte !! Es gibt auch noch so genannte .share files (auch Shell Archive genannt). Diese komme häufig in den Newsgroups vor. Näheres dazu im Software-Building-HOWTO. Dort steht auch noch einiges interessante zum Patchen von Quellpaketen und wie man Pakete in anderen Formaten wie arj, zip, lha, zoo, rar, shk oder arc behandelt

(1) Eine Pipeline leitet die Standardausgabe des Programms vor dem | - Zeichen an die Standardeingabe des folgenden Programmes weiter. Es wird auf der deutschen Tastatur erzeugt mit AltGr und der Taste für < > ! Pipelines sind wichtige Werkzeuge und man braucht sie immer wieder.

Installation Top

Das Quellarchiv hat sich sich in ein Verzeichnis entpackt und man kann jetzt schon fast loslegen! Aber wie ?? Jetzt kommt die in den Quellarchiven IMMER(2) vorhandene Dokumentation ins Spiel... Ohne die geht gar nichts !! Dokumentation liegt meistens in den Dateien README und/oder INSTALL als Textfile vor das mit jedem Editor zu öffnen ist. Meistens ist auch noch ein Unterverzeichnis doc/ da, in dem Dokumentation als html -File oder erweiterte Dokumentation als Textfile zur Verfügung steht. Lesen dieser Dokumentationen kann ich jedem nur ans Herz legen. Viele Fragen lassen sich damit schon von vornherein aus dem Weg räumen. Auch befinden sich noch andere Dateien in den Verzeichnissen, auf die man mal einen Blick mit dem Texteditor werfen sollte. Ich denke da so an das Makefile etc. Man kann dadurch nur lernen.

(2) Das stimmt leider nicht ganz, es gibt auch Quellen die wenige oder gar keine Angaben zur Installation oder der Compilierung enthalten, z.B. CVS - Versionen neuester Software oder von Beta Versionen, bei denen die Programmierer noch kein Dokumentation geschrieben haben.

Der Idealfall - oder die "GNU-autoconf"-Konforme Installation:

Bei kleineren Softwarepaketen handelt es sich oft um eine "GNU-autoconf"-Konforme Installation. Man wechselt in das Verzeichnis das aus dem entpackten Tarball entstanden ist. (Wenn man sich nicht schon längst darin befindet, denn eigentlich sollte man ja schon die Dokumentation gelesen haben ! ) Mit den folgenden Befehlen erzeugt man aus dem Quellcode des Tarballs das/die Binaries ( sozusagen den ausführbaren Programmcode ). Das ist jedoch wirklich nur Idealfall (!!!) der nicht immer zutreffen muss. Fehlermeldungen (bei ./configure oder make) die auftauchen können, werden im Troubleshooting - Abschnitt noch behandelt.

Wenn alles funktioniert hat und man das compilierte Programm getestet hat kann man die erzeugten Binaries (im Quellverzeichnis) mit make clean löschen um Festplattenplatz zu sparen. Das compilierte Programm kann sofort benutzt werden. Ferner ist oft make check (Aufruf unmittelbar nach make) zur Kontrolle ob alles gut gegangen ist vorhanden. Durch einen Blick in das Makefile und/oder die Dokumentation kann man sehen welche Optionen bei make zur Verfügung stehen !!

Das Makefile (erzeugen) und make Benutzen:

Das Makefile ist der Schlüssel zum gesammten Compilierungsprozess. In der einfachsten Form ist das Makefile ein Shellscript um einen Tarball zu compilieren. Es kann aber potenziell noch viel mehr was den Rahmen dieses FAQ - Beitrages erheblich sprengen würde. Wer daran Interesse hat kann sich im Internet dazu mehr Informationen beschaffen.

Um das Software - Building - HOWTO zu zitieren:

Das Makefile könnte man theoretisch auch weglassen, aber um ein Programm zu compilieren müsste man denn jede Datei des Quellcodes manuell übersetzen: Das folgende Beispiel ist nur eine Datei und ein größeres Programm hat hunderte davon:

Das man sich dabei leicht vertun kann und/oder wahnsinnig wird liegt auf der Hand Im Makefile wird das alles geschickt über Variablen etc. gelöst, so das das erstellen (bei ganz kleinen Softwarepaketen) nicht wirklich viel Arbeit ist ( wenn man es verstanden hat ) Nur sehr einfache Software kommt wie gesagt mit einem einfachen, durch die Autoren erstellten, Makefile aus. Komplexere Software, die Zugriff auf die verschiedensten Bibliotheken (Librarys) braucht, benötigt ein "dynamisches" Makefile oder ein Shellscript welche sich individuell an das System anpasst. Hier kommen 2 Möglichkeiten in Frage:

1)

Das Imakefile ist sozusagen ein "temporäres" Makefile. Es besteht aus Makrofunktionen und erstellt mit Hilfe von Imake das Makefile, aus dem mit make dann anschließend die Binaries erstellt werden. Dazu ein Auszug aus der man - page von Imake:

This allows machine dependencies (such as compiler options, alternate command names, and special make rules) to be kept separate from the descriptions of the various items to be built. -

Das soll es zum Imakefile gewesen sein, man trifft es IMHO eher selten an.

2)

Das uns schon bekannte configure Script ist ein Shellscript das über bestimmte Systemvariablen und selbstdefinierte Variablen das/die Makefile(s) erzeugen läßt/lassen. Configure kann man auch Informationen übergeben, wenn zum Beispiel die ein oder andere benötigte Bibliothek nicht automatisch gefunden wird (siehe Abschnitt Troubelshooting). In der Regel sucht es sich selbst unter Zuhilfenahme von der Datei /etc/ld.so.cache die richtigen Pfade zu den Bibliotheken. Ferner hat man auch die Möglichkeit anzugeben ob die Binaries statisch oder dynamisch gelinkt werden sollen. Gelinkt bedeutet, das der Programmcode der Bibliotheken nicht fest in die zu erstellenden Binaries einkompiliert wird. Dies hat den Vorteil, dass der ausführbare Programmcode schneller und auch natürlich viel kleiner ist. Statisch heisst, dass der Programmcode der Bibliotheken fest in die Binaries des Programms kompiliert wird. Ein Beispiel für ein statisches Programm ist der Netscape - Browser. Er ist deswegen so groß und träge. (Anmerkung : Die statische Linkung von Netscape hat lizenzrechtliche Gründe). Es bietet auch noch die Möglichkeit sogenanntes cross-compiling vorzubereiten. d.h. auf einem Intel System zum Beispiel ein Programm zu kompilieren, das nacher auf einer Sparc - Workstation laufen soll oder sogar auf Windows. Für letzteres ist der lame mp3 Codec ein gutes Beispiel - den kann man unter Linux auch prima für Windows kompilieren.

Tuning der erzeugten Binaries:

Damit man was von der ganzen selbstcompiliererei hat, sollen die erzeugten Binaries ja auch schneller als ein verleichbares vorkompiliertes Paket laufen. Um die Binaries zu tunen gibt es zwei Methoden:

2)

Prozessorspezifische Optimierung des Compilierungsvorganges:

Man kann wenn man über einen Prozessor mit einem erweiterten Befehlssatz verfügt ( z.B. Pentium I/II, Pentium III/IV, Athlon ) per Flags dem Compiler sagen das er diesen erweiterten Befehlssatz bei der Compilierung der Binaries berücksichtigen soll. Idealerweise erkennt das configure Script automatisch euren Proztessortyp. Das klappt jedoch nicht immer so das man durchaus die Flags entsprechend (dauerhaft) als Shellvariablen setzen kann.
Einmalig macht man das mit:

Man kann diese Zeilen auch in die Datei /etc/profile oder /etc/profile.local eintragen um diese Flags dauerhaft allen Benutzern zugänglich zu machen.

i386 läuft auf allen 386er Prozessoren und höheren Typen (3)
i486 läuft auf allen 486er Prozessoren und höheren Typen
i586 läuft auf allen Pentium kompatiblen Prozessoren und höheren Typen
i686 läuft auf allen Pentium II kompatiblen Systemen und höheren Typen

(3) i386 ist die Standardoptimierung, da Linux erst ab 386 lauffähig ist und muss nicht gesondert durch die Flags angegeben werden, außer man will auf einem höherwertigen System explizit Binaries erzeugen die auf allen Intel - kompatiblen Systemen lauffhig sind !

2)

Mit dem Programm strip:


Mit strip kann man unnötigen Code aus bereits compilierten Binaries entfernen. Das ist ganz sinnvoll um die Dateigröße klein zu halten und die Ausführungsgeschwindigkeit zu erhöhen. Gestrippt wird z.B. debugging code der eigentlich nur für Entwickler intressant ist um bei Abstürzen die Ursache herauszufinden. strip gehört zum Paket binutils

Die wichtigsten Optionen von strip sind hier gelistet:

Beispiel: Ihr befindet euch im Quellverzeichnis einer Software und wollt die Binaries und Bibliotheken strippen

Die Fehlermeldungen sind unschön aber ihr könnt sie getrost ignorieren, in den nächsten Versionen dieses HOWTOS werde ich ein passendes Script erstellen mit dem man komfortabel die Fehlersache umgehen kann bis dahin könnt ihr euch so behelfen:

Das 2>/dev/null leitet die Fehlerausgabe von strip ins Nirvana und so sind die Fehlermeldungen erstmal weg vom Bildschirm

Sinnigerweise setzt man strip unmittelbar nach dem make im Quellenverzeichnis ein. Wenn man checkinstall (siehe Abschnitt [jump=deinstallation]Deinstallation[/jump]) benutzt braucht man sich um strip keine Gedanken zu machen, die Binaries der Pakete werden, wenn man nichts anderes angibt, automatische von checkinstall gestrippt.

Deinstallation Top

Damit man die Software wieder sauber deinstallieren kann gibt es verschiedene Möglichkeiten.

make uninstall:

Eher selten ist im Makefile von den Autoren eine Uninstall - Routine enthalten. In diesen Fällen reicht ein make uninstall aus. Die installierten Binaries und Dokumentationen werden dann gelöscht. Im Zweifelsfall kann man das Makefile nach dieser Option untersuchen oder einfach mal ausprobieren.

checkinstall:

Das Tool checkinstall von Felipe Eduardo Sanchez und Diaz Duran kann bei der Installation das make install ersetzen, es dürfte allen modernen Linux - Distributionen beiliegen. Es erzeugt RPM- oder Slackware - Packete die nach Erstellen dann automatisch eingespielt werden. Bei rpm - basierten Distributionen (z.B. SuSE oder RedHat ) kann mit dem bekannten rpm - Befehl und den entsprechenden Optionen (rpm -e ) das Paket jederzeit wieder sauber deinstalliert werden. Das erstellte rpm - Paket wird auch unter /usr/src/packages/RPMS (oder /usr/src/RPM/RPMS/ je nach Distribution) und der jeweiligen Rechnerarchitektur (i386, i686 etc ) kopiert und kann danach natürlich wie jedes beliebige rpm - Paket behandelt werden. Für nähere Informationen über checkinstall bitte die README des Paketes lesen, darin enthalten ist eine detaillierte Anleitung, mögliche Funktionen und auch die Anleitung zum Erstellen von Slackware - Paketen. Das Debian Paketformat ist in den aktuellen Versionen von checkinstall natürlich auch unterstützt!
Die Homepage von checkinstall findet ihr hier

Installation in ein temporäres Verzeichnis:

Auch das ist eine Möglichkeit die man benutzen kann um Software aus Tarballs nacher wieder sauber zu Deinstallieren. Ziel des temporären Verzeichnisses ist es, eine Liste der installierten Dateien zu erstellen, anhand derer man dann später das Programm wieder entfernen kann. Die Frage ist nur, wie man das Programm in das Verzeichnis bekommt. Dazu sollte man wissen, dass man alle Optionen von configure auch make übergeben kann, d.h. die simpelste Lösung ergibt sich dann, wenn ein configure vorhanden ist. Für Pfadangaben stellt configure meist folgende Optionen zur Verfügung:

• ...
  --prefix=PREFIX
  --exec-prefix=EPREFIX
  --bindir=DIR
  --sbindir=DIR
  --libexecdir=DIR
  --datadir=DIR
  --sysconfdir=DIR
  --sharedstatedir=DIR
  --localstatedir=DIR
  --libdir=DIR
  --includedir=DIR
  --oldincludedir=DIR
  --infodir=DIR
  --mandir=DIR
  --srcdir=DIR
  ...

• install architecture-independent files in PREFIX [/usr/local]
  install architecture-dependent files in EPREFIX [same as prefix]
  user executables in DIR [EPREFIX/bin]
  system admin executables in DIR [EPREFIX/sbin]
  program executables in DIR [EPREFIX/libexec]
  read-only architecture-independent data in DIR [PREFIX/share]
  read-only single-machine data in DIR [PREFIX/etc]
  modifiable architecture-independent data in DIR [PREFIX/com]
  modifiable single-machine data in DIR [PREFIX/var]
  object code libraries in DIR [EPREFIX/lib]
  C header files in DIR [PREFIX/include]
  C header files for non-gcc in DIR [/usr/include]
  info documentation in DIR [PREFIX/info]
  man documentation in DIR [PREFIX/man]
  find the sources in DIR [configure dir or ..]
  

Man sieht hier sehr schön, dass nur --prefix von Bedeutung ist, da alle anderen Pfadangaben --prefix als Ausgangspunkt nehmen, d.h. wollen wir das Programm temporär nach /tmp/<Name>/ installieren, geht das folgendermaßen :

Allerdings fehlen noch zwei wichtige Schritte. Vor dem Installieren sollte man das temporäre Verzeichnis erst erstellen und überprüfen, ob alle Dateien auch unterhalb dieses Verzeichnisses installiert werden. Dafür hat make eine nützliche Option : -n. Damit lassen sich alle Installationschritte anzeigen aber werden nicht ausgefürt. Sollten wider Erwarten z.B. die Manpages nicht unter /tmp/<Name>/usr/local/man/ sondern unter /usr/local/man/ installiert werden, übergibt man make noch die Option mandir=/tmp/<Name>/usr/local/man/ und läßt sich erneut mit -n den Installationsablauf anzeigen. Wenn dann irgendwann alles passt, installiert man das Paket:

Jetzt hat man alle Dateien in der gleichen Hierarchie unter /tmp/<Name>/usr/local/ wie nachher unter /usr/local/. Das einzige, was man jetzt noch tun muss, ist mittels find die Dateien aufzulisten, mit sed das temporäre Verzeichnis aus jedem Dateipfad zu "schneiden" und das Ganze in einer Datei zu speichern :

Der Name und die Endung der Dateiliste ist beliebig, allerdings ist eine Bezeichnung nach Name und Version IMHO sinnvoll. Die Dateiliste speichert man da, wo man sie später bei der Deinstallation wieder findet ;-)
Zum Schluß noch das Paket mittels make install in das richtige Verzeichnis installieren und das temporäre mittels rm -rf /tmp/<Name>/ entfernen.

Um das Paket später zu deinstallieren, benötigt man noch folgendes Script, dass man z.B. unter /sbin/uninstall speichert :

Troubleshooting Top

Fehlermeldungen bei configure

Bei Fehlermeldungen bei configure nicht sofort aufgeben, meist sind nur Kleinigkeiten die Ursache. Es gilt wie immer: Die Meldungen des configure - Scripts gründlich durchzulesen. Meistens ( wenn keine Vollinstallation des Linuxsystems gewählt wurde), sind fehlende Bibliotheken, Programme oder Header - Dateien ( das sind die devel - Pakete) die Ursache, die leicht durch einspielen der entsprechenden Pakete von der Distribution CD's/DVD beheben lassen. Anmerkung: Wenn man fehlende Bibliotheken selbst compilieren möchte muss die Datei /etc/ld.so.conf noch um das Installationsverzeichnis der entsprechenden Bibliothek ergänzt werden und ldconfig ausgeführt werden. Das sollte man auch tun wenn die Bibliothek auf dem System vorhanden ist und trozdem nicht erkannt wird.

Oft ist ein Fehlschlag bei configure auch dadurch begründet, das schlicht die Verzeichnisvariablen falsch gesetzt sind. Man hat die Möglichkeit, sich mit env oder export die aktuell exportierten Shellvariablen anzeigen zu lassen und zu vergleichen, ob diese richtig gesetzt sind. Falls nicht, exportiert man sie einfach neu. Beispiel:

Wie weiter oben beschrieben kann man dies dauerhaft in der Datei /etc/profile oder /etc/profile.local eintragen. Oft tauchen auch Fehlermeldungen auf obwohl alle Bibliotheken etc. vorhanden sind aber configure sie nicht automatisch finden kann. Falls das der Grund ist kann man configure mit ensprechenden Optionen starten. Mit ./configure --help bekommt man einen Überblick über die möglichen Optionen die je nach Art und Umfang des Quellpaketes erheblich differieren.
Bevor man configure mit neuen Optionen erneut startet, sollte man erst die Datei config.cache löschen, da es sonst passieren kann, dass configure trotz richtiger Optionen fehlschlägt. In der besagten Datei wird nämlich das Ergebnis des letzten Durchlaufs gespeichert und eventuell bei einem erneuten Durchlauf direkt aus dieser Datei ( Cache ) übernommen.
Das nun folgende Beispiel ist auch auf andere Bibliotheken/Toolkits oder Programme allgemein übertragbar !! Als Beispiel dient ein Programm das auf das GTK ( GTK steht für GIMP- Tool Kit) zurückgreift. Die Programmierer habe damals nach einer Lösung gesucht, die Aufrufe in Sachen Grafik zu vereinfachen; dafür wurde das GTK geschrieben. Durch eine immer grössere Verbreitung des GTK basieren viele neue Programme darauf. Es macht jedoch trotz seiner Vereinfachungen für die Programmierung beim Kompilieren des öfteren Probleme. Um vor dem Kompilieren festzustellen, welche Version von GTK auf dem System vorhanden ist, sucht configure danach. Falls configure das GTK nicht findet (hier habe ich die Fehlermelung provoziert) erscheint eine solche Fehlermeldung :

Dann ist die Vorgehensweise relativ simpel. Man sucht die Datei gtk-config (z.B. mit locate gtk-config) und merkt sich den Pfad dahin. Dann ruft man ./configure --help auf. Man bekommt dann eine solche Bildschirmausgabe:

• 
  ...
  Features and packages:
  --disable-FEATURE
  --enable-FEATURE[=ARG]
  --with-PACKAGE[=ARG]
  --without-PACKAGE
  --x-includes=DIR
  --x-libraries=DIR
  --disable-nls
  --with-included-gettext
  --with-catgets
  --enable-debug
  --enable-socks
  --enable-openssl[=PATH]
  --enable-hebrew
  --enable-panel
  --enable-ipv6
  --disable-gtkfe
  --disable-textfe
  --disable-glib
  --disable-gnome
  --disable-zvt
  --disable-gdk-pixbuf
  --disable-xlib
  --disable-perl
  --disable-python
  --disable-plugin
  --disable-trans
  --with-glib-prefix=PFX
  --with-glib-exec-prefix=PFX
  --disable-glibtest
  --with-gtk-prefix=PFX
  --with-gtk-exec-prefix=PFX
  --disable-gtktest

• 
  do not include FEATURE (same as --enable-FEATURE=no)
  include FEATURE [ARG=yes]
  use PACKAGE [ARG=yes]
  do not use PACKAGE (same as --with-PACKAGE=no)
  X include files are in DIR
  X library files are in DIR
  do not use Native Language Support
  use the GNU gettext library included here
  use catgets functions if available
  enable use of Memory Debug (default: no)
  enable use of SOCKS5 (default: no)
  enable use of openSSL (default: no)
  enable Hebrew support (default: no)
  enable gnome panel support (default: no)
  enable IPv6 (default: no)
  disable building gtk frontend
  disable building text frontend
  disable use of glib (implies --disable-gtkfe)
  disable use of gnome
  disable zvt/shelltab feature
  disable use of gdk-pixbuf
  disable use of xlib (for non X11 systems)
  disable use of perl scripting
  disable use of python scripting
  disable plugin support
  disable translation table support
  Prefix where GLIB is installed (optional)
  Exec prefix where GLIB is installed (optional)
  Do not try to compile and run a test GLIB program
  Prefix where GTK is installed (optional)
  Exec prefix where GTK is installed (optional)
  Do not try to compile and run a test GTK program
  

Hieran sieht man mal wie umfangreich die Optionen bei configure sein können. Die Vorgehensweise ist relativ simpel. Erst löscht man die Cache - Datei (in der Regel config.cache und config.h). Man sucht dann die Datei gtk-config (z.B. locate gtk-config oder find / -name gtk-config ) und merkt sich den Pfad dahin. Dann ruft man configure mit der Option --with-gtk-prefix=/Pfad/zu/gtk-config auf :

Nachfolgend sind häufige und meist im Forum www.linuxforen.de gefundene Fehlermeldungen und deren Behebung aufgelistet:

./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion
./configure: error: C/C++ compiler cannot create executables.
./configure: error no acceptable cc found in $PATH
./configure: flex: command not found
./configure: lex: command not found
./configure: bad interpreter: No such file or directory

./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion
Dieser Fehler tritt meist bei KDE-Programmen auf, die über CVS in Verbindung mit autoconf Version 2.52 kompiliert werden. Hier hilft nur ein Downgrade auf Version 2.13.

configure: error: C/C++ compiler cannot create executables

Dieser Fehler kann durch drei Möglichkeiten auftreten: Entweder ist kein Compiler installiert und/oder die Binutils fehlen oder die Optimierungs FLAGS sind falsch gesetzt.
Fehlende Pakette dürften kein Problem darstellen, da bei jeder Distribution ein Compiler vorhanden sein sollte. Der Name des Compiler-Paketes ist meist gcc oder egcs. Die Binutils werden durch das Paket binutils abgedeckt. Sollte der Compiler und die Binutils installiert sein sollte man überprüfen ob Umgebungsvariablen gesetzt sind die den Compiler betreffen. Das sind z.B. CFLAGS und CXXFLAGS. Diese FLAGS verursachen bei manchen Programmen Probleme.Das ./configure - Script ermittelt in der Regel selber welche Art CPU im Rechner ist und setzt die FLAGS dann passend im Makefile.
Überprüfen kann man ob die FLAGS (richtig) gesetzt sind. Dazu hat man zwei Möglichkeiten:


1)

Mit export:

2)

Mit set:

Diese erstmal löschen!

Falls es dann immer noch nicht geht die Fehlermeldung von ./configure zusammen mit dem betreffenden Auszug aus der Datei config.log (meistens am Ende der Datei)im Quellverzeichnis in einem geeigneten Forum ( z.B. www.linuxforen.de ) oder einer Newsgroup posten.
Anmerkung: Oder noch besser unter online-tutorials.net/home/forum.html


./configure: error no acceptable cc found in $PATH
Es ist kein Compiler installiert oder das Verzeichnis in dem der Compiler liegt ist nicht in der PATH Variablen beinhaltet.
Ihr müsst den Compiler Nachinstallieren (wie schon hier beschrieben) oder (falls der Compiler vorhanden ist) die PATH Variable anpassen. Das geht so:

Erst lasst Ihr euch die PATH Variable anzeigen:

./configure: flex: command not found
Dir fehlt das Programm flex ( Fast Lexical Analyzer Generator ). flex ist das freie Pendant zu flex und sollte auf den CDs Deiner Distribution vorhanden sein.

./configure: lex: command not found
siehe flex

./configure: bad interpreter: No such file or directory
Dieser Fehler kann mehrere Gründe haben

1.)

Im configure - Script steht in der ersten Zeile (wie in allen Shellscripten für die bash) immer

Wenn es danach noch nicht funktioniert ist eine Lösung höchtwarscheinlich durch die nächsten Möglichkeiten zu erreichen.

2.)

Das [i]configure - Script ist nicht ausführbar als markiert. Das kann man mit dem Programm chmod aber ändern. Ein ls -la zeigt die Dateien samt Rechten und Besitzer und Gruppe an

Hier ist also alles in Ordnung, das Script ist ausführbar für den Besitzer, die Gruppe und Andere wie man an -rwxr-xr-x erkennt. Falls das nicht so ist (wie hier bei configure.in (diese Datei muss nicht ausführbar sein, sie dient lediglich als Beispiel) kommt chmod in's Spiel. Ich will hier nur generell zeigen wie es geht und keine Abhandlung zum Rechtesystem unter Linux/UNIX machen, daher nur das nötigste. Bitte lest die entsprechenden Manual Pages und weitere Dokumentation zum Rechtesystem unter Unixderivaten ! Um die Rechte zu ändern braucht ihr schreibenden Zugriff auf die Datei.Wie man an -rw-r--r-- bei configure.in sieht hat dieses Recht nur ivens als Besizter oder natürlich root. Ein einfaches

reicht aus um der Datei die passenden Ausführungsrechte zu geben. Ich bevorzuge diese oktale Schreibweise (755) um die Rechte zu vergeben da es weniger Tipparbeit ist. Andere Wege sind auch möglich und in der Manpage von chmod beschrieben.

3.)

Die Datei ist unter Windows entpackt worden ! Man glaubt es kaum, es gibt tatsächlich Unterschiede zwischen Textdateien auf Windows/DOS Systemen und Linux Systemen. Nämlich die Zeilenumbrüche bzw. die Codierung des Textes. Unter Windows ist der Text als ibmpc codiert, unter Linux hingegen als latin1.
Das folgende Beispiel ist eine unter Windows mit einem Texteditor erstellte Datei mit joe unter Linux geöffnet. Achtung: less und der Editor vom Midnight Commander mc können mit beiden Codierungen was anfangen und zeigen die Zeilenumbruchszeichen nicht an, somit ist das Problem also nicht zu erkennen !

Es ist also nicht weiter verwunderlich das configure Bad Interpreter meldet, denn es gibt keine Datei /usr/bin/sh^M. Aber wie gesagt, das gleiche kann auch durch auspacken unter Windows passieren. Um diese Datei(en) wieder in die linuxtypische latin1 - Codierung umzuwandeln kann man das Programm recode benutzen.

Idealerweise macht man das für das ganze Quellverzeichnis inclusive der Unterverzeichnisse im Quellcode folgendermaßen:

Andersrum geht es natürlich auch, das wird man aber selten brauchen

Fehlermeldungen bei make Top

Ein Patentrezept für eine Lösung von Fehlern bei make gibt es leider nicht. Es kommt aber eigentlich sehr selten vor, dass bei stabiler gut getesteter Software nach einem erfolgreichen configure - Aufruf der make - Aufruf fehlschägt - wenn man Murphy mal außen vor läßt Wird aber Beta Software ( ganz kleine Versionsnummern, CVS - Snapshots, etc ) verwendet, kommt es öfter vor das make mit einem Fehler abbricht. Da kann man als Linuxneuling oder noch nicht so erfahrener Benutzer (ohne Programmierkenntnisse) eigentlich nicht viel machen außer auf eine neue Version zu warten (was meißtens sehr schnell geht, da nicht nur du das Problem hast ).
Nachfolgend sind häufig gefundene Fehlermeldungen und deren Behebung aufgelistet:

make: command not found
make[2]: *** [irgendwas.o] Error 1
make[1]: *** Warning: File `Makefile.in´ has modification time in the future...

make: command not found

Das Programm make ist auf deinem System nicht installiert. Am besten per RPM von den Distributions CD's nachinstallieren

make[2]: *** [irgendwas.o] Error 1

Ein klassischer Fall von einer fehlenden Header-Datei.
In der Datei discdb.c in Zeile 39 wird auf die Header-Datei ghttp.h verwiesen die nicht da ist oder nicht gefunden wird. Das entsprechende Paket muss nachinstalliert werden. Diese Dateien sollten unter /usr/include/ oder /usr/local/include legen. Wenn diese Header-Datei allerdings da ist aber nicht gefunden werden weil sie z.B unter /usr/local/include liegt, aber unter /usr/include erwartet werden (oder umgekehrt) kann man einen entsprechenden Link setzen Natürlich kann man in diesem Fall auch die Datei discdb.c im Quellcode des Programms verändern.
Wenn Header - Dateien aus /usr/include/linux fehlen habt ihr die Kernelquellen nicht installiert. Diese sind wichtig wenn Kernelmodule nachkompilieren wollt (z.B. die Nvidia® Grafikkartentreiber aus den Tarballs oder den src.RPM's ).

make[1]: *** Warning: File `Makefile.in´ has modification time in the future...
Das Problem tritt auf wenn wenn die Quellen "brandneu" sind und z.B. auf einem Computer in einer anderen Zeitzone erstellt worden sind (die uns vorraus ist) oder die Uhr auf dem Rechner auf dem sie erstellt worden sind eine Uhrzeit aus der Zukunft hat, also vor geht. Die Lösung ist sehr einfach. Man verwendet das Programm touch und "berührt" die Dateien mal kurz.

Dokumentation, Quellen und Hilfe Top

Software-Building-Howto - Eine weitere Anlaufstelle für Hilfe zum Kompilieren von Quellpaketen, allerdings auf englisch. Trotzdem ist die Seite auf alle Fälle einen Besuch wert
Compiling and installing software from sources - Ein nettes einfaches aber englisches Tutorial von IBM (http://www.ibm.com/developerworks/). Man muss sich kostenlos registrieren und hat zugriff auf jede Menge guter englischer Tutorials !!
linuxforen.de -- User helfen Usern - DAS deutschsprachige Linux - Forum. Man kann sich kostenlos registrieren oder einfach ohne Anmeldung mitlesen !! Hier findet man über 79.000 Themen und 440.000 Beiträge von über 15.000 Usern zu Themen rund um Linux. Es bietet alles für Newbies und für Profis ... und alles auf deutsch
Das c't Linuxforum für Newbies - c't Leser & Redaktion helfen Linux Newbies Natürlich auch alles auf deutsch

Autor Top

Autor dieser FAQ ist Ulrich Ivens bei Verbesserungsvorschlägen oder Anregungen zu dieser FAQ bitte ich um eine eMail (ulrich.ivens@gmx.de), oder besucht meine Homepage hier oder hier. Bedanken möchte ich mich für die Unterstüzung von Michael Aichler (Homepage]) im Bereich "Installation in ein temporäres Verzeichnis" und "Troubleshooting"!

Ulrich Ivens beschäftigt sich seit Mitte 2000 intensiv mit Linux und hat diese FAQ ursprünglich für sich selbst geschrieben. Da die Community aber vom mitmachen lebt hat er sich entschlossen diesen Beitrag zu veröffentlichen. Die ursprünglich Version 1.0 Dieser FAQ ist hier zu finden.

Lizenz Top

Dieser Beitrag steht unter der "GNU Free Documentation License GFDL" nachzulesen unter: www.gnu.org/copyleft/fdl.html

Copyright (c) Ulrich Ivens.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?

Editieren Versionen Linkpartnerschaft Top Printversion

Haben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Installation von Software aus Quellarchiven unter Linux