PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Installation von Software aus Quellarchiven



Ulli Ivens
19.12.01, 18:57
<!-- FAQ BEGIN -->

<a name=topdoc></A>
<li><a href=#SRC-ZuDieserFaq>Zu dieser FAQ</a></li>
<li><a href=#SRC-Allgemein>Allgemein</a></li>
<li><a href=#SRC-Entpacken>Entpacken der Archive</a></li>
<li><a href=#SRC-Installation>Installation</a></li>
<li><a href=#SRC-Deinstall>Deinstallation</a></li>
<li><a href=#SRC-Trouble>Troubleshooting</a></li>
<li><a href=#SRC-Dokumentation>Dokumentation</a></li>
<li><a href=#SRC-Lizenz>Lizenz</a></li>

<br><br><hr><br><br>

<!--ZU DIESER FAQ -->
<h2>
<a name=SRC-ZuDieserFaq>Zu dieser FAQ</a>
</h2>
<p>
Dieser Abschnitt der FAQ soll die Installation von Software unter Linux aus
Quellarchiven, sogenannten &quot;Tarballs&quot; verdeutlichen. Er
soll grunds&auml;tzliche Hilfe zu Problemen und Fehlermeldungen geben
und verdeutlichen wie die Konfiguration und Installation grob
funktioniert. Prim&auml;r angesprochen werden Linuxneulinge und noch
nicht so erfahrende Linux - Anwender.
</p>

<br><br><hr><br><br>

<!--ALLGEMEIN -->
<h2>
<a name=SRC-Allgemein>Allgemein</a>
</h2>
<p>
Quellarchive liegen in der Regel als folgende Dateien vor, jenachdem welcher Packalgorithmus vom Verfasser
des Paketes verwendet wurde.
<p>
<b>-</b>&nbsp;<b>tar</b> (unkomprimiert),<br>
<b>-</b>&nbsp;<b>tar.Z</b>,<br>
<b>-</b>&nbsp;<b>tar.gz</b> oder <b>tgz</b>, was das selbe ist,<br>
<b>-</b>&nbsp;<b>tar.bz2</b><br>
</p>
In Tarballs steht der reine Quellcode welchen man mit den entsprechenden Kenntnissen der jeweiligen
Programmiersprache leicht verifizieren kann oder bei Bedarf und endsprechender Lizenz unter der die
Software ver&ouml;ffentlicht wurde &auml;ndern/erweitern kann. Der gleiche Tarball kann auf verschiedenen
UNIX - Derivaten compiliert werden. Dadurch wird der Autor der Software davor bewart, verschiedene Versionen
zu schreiben.
</p>

<br><br><hr><br><br>

<!-- ENTPACKEN DER ARCHIVE -->
<h2>
<a name=SRC-Entpacken>Entpacken der Archive</a>
</h2>
<p>
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&uuml;r ein unkomprimiertes tar-Archiv und die jeweiligen Packalgorithmen die
Vorgehensweise auf der Shell:
</p>
<table width=100%>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
tar -xvf &lt;Name&gt;.tar<br>
</code></font></td></tr>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
tar -xvZf &lt;Name&gt;.tar.Z<br>
</code></font></td></tr>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
tar -xvzf &lt;Name&gt;.tar.gz<br>
</code></font></td></tr>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
tar -xvjf &lt;Name&gt;.tar.bz2<br>
</code></font></td></tr>
</table>
<br>
Es kann auch sein das <i>tar</i> nicht mit bz2 Archiven arbeiten kann (bei &auml;lteren Linux Distributionen und anderen
UNIX - Derivaten, die nicht &uuml;ber GNU/tar verf&uuml;gen). Dann kann man diese Archive folgenderma&szlig;en
&uuml;ber eine Pipeline entpacken:
<br><br>
<table width=100%>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
cat &lt;Name&gt;.tar.bz2 | bzip -d | tar xvf -
</code></font></td></tr>
<tr><td bgcolor=white height=25><font color=#0000C0><code>
bzcat &lt;Name&gt;.tar.bz2 | tar xv <br>
</code></font></td></tr>
</table>

<p>
Informationen zu <b>tar</b>, <b>gzip</b> und <b>bzip2</b> findet man in der entsprechenden ManPage die man sich
unbedingt zu Gem&uuml;te f&uuml;hren sollte !! Es gibt auch noch sogenannte <b>share files</b> (auch Shell Archive genannt). Diese kommen
h&auml;ufig in den Newsgroups vor. N&auml;heres dazu im <a href="http://www.linuxdoc.org/HOWTO/Software-Building-HOWTO.html">
Software-Building-HOWTO</a>. 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.
</p>

<br><br><hr><br><br>

<!-- INSTALLATION -->
<h2>
<a name=SRC-Installation>Installation</a>
</h2>
<p>
Das Quellarchiv hat sich sich in ein Verzeichnis entpackt und man kann jetzt schon fast loslegen! Aber wie ??
Jetzt kommt die in den Quellarchiven <b>IMMER</b><sup>1</sup> vorhandene Dokumentation ins Spiel... Ohne die geht gar nichts !!
Dokumentation liegt meistens in den Dateien <b>README</b> und/oder <b>INSTALL</b> 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.
<br><br>
<table>
<tr>
<td valign=top><sup><b>1</b></sup></td>
<td>
Das stimmt leider nicht immer, 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 ProgrammiererInnen noch keine
Dokumentation geschrieben haben.
</td>
</tr>
</table>
</p>

<p><u>Der Idealfall - oder die "GNU-autoconf"-Konforme Installation:</u></p>
<p>
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&auml;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&uuml;hrbaren Programmcode ). Das ist jedoch wirklich nur Idealfall (!!!) der nicht immer zutreffen muss.
Fehlermeldungen (bei ./configure oder make) die auftauchen k&ouml;nnen, werden im Troubelshooting - Abschnitt noch behandelt.
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
./configure
</code></font></td></tr>
<tr><td>
Script das &uuml;berpr&uuml;ft ob alle Voraussetzung f&uuml;r die Compilierung erf&uuml;llt sind
</td></tr>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
make
</code></font></td></tr>
<tr><td>
die eigentliche Compilierung, d.h. Erzeugung des ausf&uuml;rbaren Programmcodes
</td></tr>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
make install
</code></font></td></tr>
<tr><td>
die eigentliche Installation - in der Regel als root ausgef&uuml;hrt
</td></tr>
</table>
<p>
Wenn alles funktioniert hat und man das compilierte Programm getestet hat kann man die erzeugten Binaries (im Quellverzeichnis)
mit make clean l&ouml;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&uuml;gung stehen !!
</p>

<p><u>Das Makefile (erzeugen) und make Benutzen:</u></p>

Das Makefile ist der Schl&uuml;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&uuml;rde. Wer daran Interesse hat kann sich im Internet dazu mehr Informationen beschaffen.
<p>
Um das Software - Building - HOWTO zu zitieren:<br>
<i>An manchen Punkten startet das Makefile cc oder gcc. Das sind ein Pr&auml;prozezzor, ein C (oder C++) Compiler und ein Linker.
Dieser Prozess konvertiert die Quellpakete in die ausfu"rbaren Binaries.</i>
</p>
Das Makefile k&ouml;nnte man theoretisch auch weglassen, aber um ein Programm zu compilieren m&uuml;sste man denn jede Datei
des Quellcodes manuell &uuml;bersetzen:
Das folgende Beispiel ist nur <b>eine</b> Datei und ein gr&ouml;&szlig;eres Programm hat hunderte davon:
<br><br>
<table>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include -DNEED_GNOMESUPPORT_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -I/opt/gnome/include -I/opt/gnome/lib/gnome-libs/include -I/usr/X11R6/include
-I/usr/include/glib-1.2 -I/usr/include/gtk-1.2 -I/usr/include/python2.1 -I/usr/lib/glib/include -I/usr/lib/perl5/5.6.1/i586-linux/CORE
-I/usr/local/include -O2 -Wall -fno-strict-aliasing -g -pipe -c urlgrab.c
</code></font></td></tr>
</table>
<p>
Das man sich dabei leicht vertun kann und/oder wahnsinnig wird liegt auf der Hand ;) Im Makefile wird das alles geschickt &uuml;ber
Variablen etc. gel&ouml;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&ouml;tigt ein "dynamisches" Makefile oder ein Shellscript
welche sich individuell an das System anpasst. Hier kommen 2 M&ouml;glichkeiten in Frage:
</p>
<ol>
<li>
Das <b>Imakefile</b> ist sozusagen ein &quot;tempor&auml;res&quot; Makefile. Es besteht aus Makrofunktionen und erstellt mit
Hilfe von Imake das Makefile, aus dem mit make dann anschlie&szlig;end die Binaries erstellt werden.
Dazu ein Auszug aus der man - page von Imake:
<p><i>
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. -
</i></p>
Das soll es zum Imakefile gewesen sein, man trifft es IMHO eher selten an.
</li>
<br>
<li>
Das uns schon bekannte configure Script ist ein Shellscript das &uuml;ber bestimmte Systemvariablen
und selbstdefinierte Variablen das/die Makefile(s) erzeugen l&auml;ßt/lassen. Configure kann man auch
Informationen &uuml;bergeben, wenn zum Beispiel die ein oder andere ben&auml;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&uuml;hrbare Programmcode schneller und auch nat&uuml;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&uuml;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&uuml;r letzteres ist der lame mp3 Codec
ein gutes Beispiel - den kann man unter Linux auch prima für Windows kompilieren.
</li>
</ol>

<br><br><hr><br><br>

<!-- DEINSTALLATION -->
<h2>
<a name=SRC-Deinstall>Deinstallation</a>
</h2>
<p>
Damit man die Software wieder sauber deinstallieren kann gibt es verschiedene M&ouml;glichkeiten.
</p>
<u>make uninstall:</u>
<p>
Eher selten ist im Makefile von den Autoren eine Uninstall - Routine enthalten. In diesen F&auml;llen reicht ein
&lt;<b>make uninstall</b>&gt; aus. Die installierten Binaries und Dokumentationen werden dann gel&auml;scht. Im
Zweifelsfall kann man das Makefile nach dieser Option untersuchen oder einfach mal ausprobieren.
</p>
<u>Checkinstall:</u>
<p>
Das Tool <b>checkinstall</b> von Felipe Eduardo Sanchez und Diaz Duran kann bei der Installation das make install ersetzen,
es d&uuml;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 und der jeweiligen Rechnerarchitektur (i386, i686 etc ) kopiert und kann danach nat&uuml;rlich
wie jedes beliebige rpm - Paket behandelt werden.
F&uuml;r n&auml;here Informationen &uuml;ber checkinstall bitte die README des Paketes lesen, darin enthalten ist eine
detailierte Anleitung, m&ouml;gliche Funktionen und auch die Anleitung zum Erstellen von Slackware - Paketen. Das Debian
Paketformat soll in den n&auml;chsten Versionen von checkinstall auch unterst&uuml;tzt werden.
</p>

<u>Installation in ein tempor&auml;res Verzeichnis:</u>
<p>
Auch das ist eine M&ouml;glichkeit die man benutzen kann um Software aus Tarballs nacher wieder sauber zu Deinstallieren.
Ziel des tempor&auml;ren Verzeichnisses ist es, eine Liste der installierten Dateien zu erstellen, anhand derer man dann
sp&auml;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 <i>configure</i> auch <i>make</i> &uuml;bergeben kann, d.h.
die simpelste L&ouml;sung ergibt sich dann, wenn ein <i>configure</i> vorhanden ist. F&uuml;r Pfadangaben stellt <i>configure</i>
meist folgende Optionen zur Verf&uuml;gung:
<br><br>
<table width=100% border=0>
<tr valign=left>
<td bgcolor=white height=25 ><font color=#0000C0><code><pre>
...
--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
...
</pre></code></font></td>
<td bgcolor=white height=25><font color=#0000C0><code><pre>
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 ..]
</pre></code></font></td>
</tr>
</table>
<br><br>
Man sieht hier sehr sch&ouml;n, dass nur <i>--prefix</i> von Bedeutung ist, da alle anderen Pfadangaben <i>--prefix</i> als
Ausgangspunkt nehmen, d.h. wollen wir das Programm tempor&auml;r nach <i>/tmp/&lt;Name&gt;/</i> installieren, geht das
folgenderma&szlig;en :
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
make prefix=/tmp/&lt;Name&gt;/usr/local/ install
</code></font></td></tr>
</table>
<br><br>
Allerdings fehlen noch zwei wichtige Schritte. Vor dem Installieren sollte man das tempor&auml;re Verzeichnis erst erstellen und
&uuml;berpr&uuml;fen, ob alle Dateien auch unterhalb dieses Verzeichnisses installiert werden. Daf&uuml;r hat <i>make</i>
eine n&uuml;tzliche Option : <i>-n</i>. Damit lassen sich alle Installationschritte anzeigen aber werden nicht ausgef&uuml;rt.
Sollten wider Erwarten z.B. die Manpages nicht unter <i>/tmp/&lt;Name&gt;/usr/local/man/</i> sondern unter <i>/usr/local/man/</i>
installiert werden, &uuml;bergibt man <i>make</i> noch die Option <i>mandir=/tmp/&lt;Name&gt;/usr/local/man/</i> und
l&auml;&szlig;t sich erneut mit <i>-n</i> den Installationsablauf anzeigen. Wenn dann irgendwann alles passt, installiert man
das Paket:
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
mkdir /tmp/&lt;Name&gt;/<br>
make -n prefix=/tmp/&lt;Name&gt;/usr/local/ install | less <br>
make prefix=/tmp/&lt;Name&gt;/usr/local/ install
</code></font></td></tr>
</table>
<br><br>
Jetzt hat man alle Dateien in der gleichen Hierarchie unter <i>/tmp/&lt;Name&gt;/usr/local/</i> wie nachher unter <i>/usr/local/</i>.
Das einzige, was man jetzt noch tun muss, ist mittels <i>find</i> die Dateien aufzulisten, mit <i>sed</i> das tempor&auml;re
Verzeichnis aus jedem Dateipfad zu &quot;schneiden&quot; und das Ganze in einer Datei zu speichern :
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
find /tmp/&lt;Name&gt;/ ! -type d | sed -e 's|/tmp/&lt;Name&gt;||' \<br>
>> &lt;Name&gt;-&lt;Version&gt;.liste
</code></font></td></tr>
</table>
<br>
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&auml;ter bei der Deinstallation wieder findet ;-)<br>
Zum Schlu&szlig; noch das Paket mittels <i>make install</i> in das richtige Verzeichnis installieren und das tempor&auml;re
mittels <i>rm -rf /tmp/&lt;Name&gt;/</i> entfernen.
<br><br>
Um das Paket sp&auml;ter zu deinstallieren, ben&ouml;tigt man noch folgendes Script, dass man z.B. unter <i>/sbin/uninstall</i>
speichert :
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code><pre>
#!/bin/sh

if [ -f "$1" ]; then
for file in $(cat "$1"); do
rm -v $file 2>/dev/null
done
else
# Dateiliste exisitiert nicht
echo "Benutzung: $0 &lt;Dateiliste&gt;"
exit 1
fi

exit 0
</pre></code></font></td></tr>
</table>
<br><br>
</p>

<br><br><hr><br><br>

<!-- TROUBLESHOOTING -->
<h2>
<a name=SRC-Trouble>Troubleshooting</a>
</h2>
<p>
<ul>
<li>
<u> Fehlermeldungen bei <i>configure</i></u>
<br><br>
Bei Fehlermeldungen bei <i>configure</i> nicht sofort aufgeben, meist sind nur Kleinigkeiten die Ursache. Es gilt wie immer:
Die Meldungen des configure - Scripts gr&uuml;ndlich durchzulesen. Meistens ( wenn keine Vollinstallation des Linuxsystems
gew&auml;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&auml;nzt werden und ldconfig ausgef&uuml;hrt werden.
Das sollte man auch tun wenn die Bibliothek auf dem System vorhanden ist und trozdem nicht erkannt wird.
<br><br>
Oft ist ein Fehlschlag bei configure auch dadurch begr&uuml;ndet, das schlicht die Verzeichnisvariablen falsch gesetzt sind.
Man hat die Möglichkeit, sich mit <b>env</b> oder <b>export</b> die aktuell exportierten Shellvariablen anzeigen zu lassen
und zu vergleichen, ob diese richtig gesetzt sind. Falls nicht, exportiert man sie einfach neu. Beispiel:
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
export KDEDIR=/opt/kde2
</code></font></td></tr>
</table>
<br><br>
Man kann dies auch dauerhaft in der Datei <i>/etc/profile</i> oder <i>/etc/profile.local</i> 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 &Uuml;berblick &uuml;ber die m&ouml;glichen Optionen die je nach Art und Umfang des
Quellpaketes erheblich differieren.
<br>
Bevor man <i>configure</i> mit neuen Optionen erneut startet, sollte man erst die Datei <i>config.cache</i> l&ouml;schen,
da es sonst passieren kann, dass <i>configure</i> trotz richtiger Optionen fehlschl&auml;gt. In der besagten Datei
wird n&auml;mlich das Ergebnis des letzten Durchlaufs gespeichert und eventuell bei einem erneuten Durchlauf direkt aus dieser
Datei ( Cache ) &uuml;bernommen.
<br>
Das nun folgende Beispiel ist auch auf andere Bibliotheken/Toolkits &uuml;bertragbar !!
Als Beispiel dient ein Programm das auf das <i>GTK</i> ( GTK steht für GIMP- Tool Kit) zurückgreift. Die Programmierer habe
damals nach einer L&ouml;sung gesucht, die Aufrufe in Sachen Grafik zu vereinfachen; daf&uuml;r wurde das <i>GTK</i>
geschrieben. Durch eine immer gr&auml;ssere Verbreitung des <i>GTK</i> basieren viele neue Programme darauf.
Es macht jedoch trotz seiner Vereinfachungen f&uuml;r die Programmierung beim Kompilieren des &ouml;fteren Probleme.
Um vor dem Kompilieren festzustellen, welche Version von <i>GTK</i> auf dem System vorhanden ist, sucht <i>configure</i>
danach. Falls configure das <i>GTK</i> nicht findet (hier habe ich die Fehlermelung provoziert) erscheint eine solche
Fehlermeldung :
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code><pre>
....
checking for gtk-config... /usr/local/bin/gtk-config
checking for GTK - version >= 1.2.0... no
./configure: /usr/local/bin/gtk-config: Datei oder Verzeichnis nicht gefunden

*** Could not run GTK test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK was incorrectly installed
*** or that you have moved GTK since it was installed. In the latter case, you
*** may want to edit the gtk-config script: /usr/local/bin/gtk-config

Cannot find GTK! Not building GTK FrontEnd.
...
</pre></code></font></td></tr>
</table>
<br><br>
Dann ist die Vorgehensweise relativ simpel. Man sucht die Datei <i>gtk-config</i> (z.B. locate gtk-config) und merkt sich
den Pfad dahin. Dann ruft man <i>./configure --help</i> auf. Man bekommt dann eine solche Bildschirmausgabe:
<br><br>
<table width=100% border=0>
<tr valign=top>
<td bgcolor=white height=25><font color=#0000C0><code><pre>
...
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
<b>--with-gtk-prefix=PFX</b>
--with-gtk-exec-prefix=PFX
--disable-gtktest
</pre></code></font></td>
<td bgcolor=white height=25><font color=#0000C0><code><pre>



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
<b>Prefix where GTK is installed (optional)</b>
Exec prefix where GTK is installed (optional)
Do not try to compile and run a test GTK program
</code></font></td>
</tr>
</table>
<br><br>
Hieran sieht man mal wie umfangreich die Optionen bei <i>configure</i> sein k&auml;nnen. Die Vorgehensweise ist relativ simpel.
Erst l&ouml;scht man die Cache - Datei (in der Regel config.cache). Man sucht dann die Datei <i>gtk-config</i> (z.B. locate
gtk-config oder find / -name gtk-config ) und merkt sich den Pfad dahin. Dann ruft man <i>configure</i> mit der Option
<i>--with-gtk-prefix=/Pfad/zu/gtk-config</i> auf :
<br><br>
<table width=100%>
<tr ><td bgcolor=white height=25><font color=#0000C0><code>
spookys:/usr/local/src/programme/xchat-1.8.4# rm config.cache<br>
spookys:/usr/local/src/programme/xchat-1.8.4# locate gtk-config<br>
/usr/bin/gtk-config<br>
/usr/share/man/man1/gtk-config.1.gz<br>
/usr/X11R6/bin/wxgtk-config<br>
spookys:/usr/local/src/programme/xchat-1.8.4# ./configure --with-gtk-prefix=/usr<br>
creating cache ./config.cache<br>
...... <br>
checking for gtk-config... /usr/bin/gtk-config<br>
checking for GTK - version >= 1.2.0... yes<br>
......
</code></font></td></tr>
</table>
<br><br>
Nachfolgend sind h&auml;ufige und meist hier im Forum gefundene Fehlermeldungen und deren Behebung aufgelistet:
<br><br>

<!-- QUESTIONS -->
<a href=#Q_SRC_C01>
./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion</a><br>
<a href=#Q_SRC_C02>
./configure: error: C/C++ compiler cannot create executables.</a><br>
<a href=#Q_SRC_C03>
./configure: flex: command not found</a><br>
<a href=#Q_SRC_C04>
./configure: lex: command not found</a><br>
<br><br>

<a name=Q_SRC_C01></a>
<u>./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion.</u><br>
Dieser Fehler tritt meist bei KDE-Programmen auf, die &uuml;ber CVS in Verbindung mit
autoconf Version 2.52 kompiliert werden. Hier hilft nur ein Downgrade auf Version 2.13.
<br><br>
<a name=Q_SRC_C02></a>
<u>configure: error: C/C++ compiler cannot create executables.</u><br>
Dieser Fehler tritt auf, wenn entweder kein Compiler installiert ist, oder die FLAGS falsch gesetzt sind.
Ersteres d&uuml;rfte aber kein Problem darstellen, da bei jeder Distribution ein Compiler vorhanden sein
sollte. Der Name des Compiler-Pakete´s ist meist <b>gcc</b> oder <b>egcs</b>.
Sollte der Compiler installiert sein, am Besten die Fehlermeldung von configure zusammen mit dem
betreffenden Auszug aus der <i>config.log</i> im gleichen Verzeichnis hier im Forum posten.
<br><br>
<a name=Q_SRC_C03></a>
<u>./configure: flex: command not found</u><br>
Dir fehlt das Programm <i>flex</i> ( Fast Lexical Analyzer Generator ). <i>Flex</i> ist das freie Pendant zu <i>lex</i> und
sollte auf den CDs Deiner Distribution vorhanden sein.
<br><br>
<a name=#Q_SRC_C04></a>
<u>./configure: lex: command not found</u><br>
siehe <a href="Q_SRC_C03">flex</a>
</li>
<br><br>
<li>
<u> Fehlermeldungen bei <i>make</i></u>
<br><br>
Ein Patentrezept für eine L&ouml;sung von Fehlern bei <i>make</i> gibt es leider nicht. Es kommt aber eigentlich sehr selten vor, dass
bei stabiler gut getesteter Software nach einem erfolgreichen <i>configure</i> - Aufruf der <i>make</i> - Aufruf fehlsch&auml;gt -
wenn man Murphy mal au&szlig;en vor l&auml;t ;) <br>
Wird aber Beta Software ( ganz kleine Versionsnummern, CVS - Snapshots, etc ) verwendet, kommt es &ouml;fter vor das <i>make</i>
mit einem Fehler abbricht. Da kann man als Linuxneuling oder noch nicht so erfahrener Benutzer (ohne Programmierkenntnisse) eigentlich
nicht viel machen au&szlig;er auf eine neue Version zu warten (was mei&szlig;tens sehr schnell geht, da nicht nur du das Problem hast ;) ).
<br>
Nachfolgend sind h&auml;ufige und meist hier im Forum gefundene Fehlermeldungen und deren Behebung aufgelistet:
<br><br>

<a href=#Q_SRC_M01>
make: command not found</a><br>
<br><br>

<a name=Q_SRC_M01></a>
<u>make: command not found</u><br>
Das Programm <i>make</i> ist auf Deinem System nicht installiert.
<br><br>
</ul>
</p>

<br><br><hr><br><br>

<!-- DOKUMENTATION -->
<h2>
<a name=SRC-Dokumentation>Dokumentation</a>
</h2>
<br><br>

<table>
<tr>
<td valign=top>
<a href="http://www.linuxdoc.org/HOWTO/Software-Building-HOWTO.htm" target="_blank">
Software-Building-Howto</a>&nbsp;
</td>
<td>
Eine weitere Anlaufstelle f&uuml;r Hilfe zum Kompilieren von Quellpaketen,
allerdings auf englisch. Trotzdem ist die Seite auf alle F&auml;lle einen Besuch wert ;)
</td>
</tr>
<tr>
<td valign=top>
<a href="http://www.ibm.com/developerworks/" target="_blank">
Compiling and installing software from sources</a>&nbsp;
</td>
<td>
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 Tutorials !!
</td>
</tr>

</table>



<br><br><hr><br><br>

<!-- LIZENZ -->
<h2>
<a name=SRC-Lizenz>Lizenz</a>
</h2>
<br><br>
Dieser Beitrag steht unter der &quot;GNU Free Documentation License GFDL&quot; nachzulesen unter:
<a href=http://www.gnu.org/copyleft/fdl.html>http://www.gnu.org/copyleft/fdl.html</a>

<br><br><hr><br><br>

<!-- FAQ END -->

Ulli Ivens
26.03.02, 21:35
gelöscht

Ulli Ivens
31.05.03, 13:49
Ich habe eine neue Version fertig gestellt. Wichtig ist auch das sich die URL geändert hat. Ab sofort findet Ihr das HOWTO unter:

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