- Zu dieser FAQ
- Allgemein
- Entpacken der Archive
- Installation
- Deinstallation
- Troubleshooting
- Dokumentation
- Lizenz
Zu dieser FAQ
Dieser Abschnitt der FAQ soll die Installation von Software unter Linux aus
Quellarchiven, sogenannten "Tarballs" verdeutlichen. Er
soll grundsätzliche Hilfe zu Problemen und Fehlermeldungen geben
und verdeutlichen wie die Konfiguration und Installation grob
funktioniert. Primär angesprochen werden Linuxneulinge und noch
nicht so erfahrende Linux - Anwender.
Allgemein
Quellarchive liegen in der Regel als folgende Dateien vor, jenachdem 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 endsprechender 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 bewart, verschiedene Versionen
zu schreiben.
Entpacken der Archive
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:
tar -xvf <Name>.tar
tar -xvZf <Name>.tar.Z
tar -xvzf <Name>.tar.gz
tar -xvjf <Name>.tar.bz2
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). Dann kann man diese Archive folgendermaßen
über eine Pipeline entpacken:
cat <Name>.tar.bz2 | bzip -d | tar xvf -
bzcat <Name>.tar.bz2 | tar xv
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 sogenannte share files (auch Shell Archive genannt). Diese kommen
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.
Installation
Das Quellarchiv hat sich sich in ein Verzeichnis entpackt und man kann jetzt schon fast loslegen! Aber wie ??
Jetzt kommt die in den Quellarchiven IMMER1 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.
1
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.
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 Troubelshooting - Abschnitt noch behandelt.
./configure
Script das überprüft ob alle Voraussetzung für die Compilierung erfüllt sind
make
die eigentliche Compilierung, d.h. Erzeugung des ausfürbaren Programmcodes
make install
die eigentliche Installation - in der Regel als root ausgeführt
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:
An manchen Punkten startet das Makefile cc oder gcc. Das sind ein Präprozezzor, ein C (oder C++) Compiler und ein Linker.
Dieser Prozess konvertiert die Quellpakete in die ausfu"rbaren Binaries.
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:
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
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:
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.
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.
Deinstallation
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 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
detailierte Anleitung, mögliche Funktionen und auch die Anleitung zum Erstellen von Slackware - Paketen. Das Debian
Paketformat soll in den nächsten Versionen von checkinstall auch unterstützt werden.
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 :
make prefix=/tmp/<Name>/usr/local/ install
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:
mkdir /tmp/<Name>/
make -n prefix=/tmp/<Name>/usr/local/ install | less
make prefix=/tmp/<Name>/usr/local/ install
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 :
find /tmp/<Name>/ ! -type d | sed -e 's|/tmp/<Name>||' \
>> <Name>-<Version>.liste
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 :
#!/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 <Dateiliste>"
exit 1
fi
exit 0
Troubleshooting
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:
export KDEDIR=/opt/kde2
Man kann dies auch 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 ü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 :
....
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.
...
Dann ist die Vorgehensweise relativ simpel. Man sucht die Datei gtk-config (z.B. 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). 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 :
spookys:/usr/local/src/programme/xchat-1.8.4# rm config.cache
spookys:/usr/local/src/programme/xchat-1.8.4# locate gtk-config
/usr/bin/gtk-config
/usr/share/man/man1/gtk-config.1.gz
/usr/X11R6/bin/wxgtk-config
spookys:/usr/local/src/programme/xchat-1.8.4# ./configure --with-gtk-prefix=/usr
creating cache ./config.cache
......
checking for gtk-config... /usr/bin/gtk-config
checking for GTK - version >= 1.2.0... yes
......
Nachfolgend sind häufige und meist hier im Forum 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: flex: command not found
./configure: lex: command not found
./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 tritt auf, wenn entweder kein Compiler installiert ist, oder die FLAGS falsch gesetzt sind.
Ersteres dürfte aber kein Problem darstellen, da bei jeder Distribution ein Compiler vorhanden sein
sollte. Der Name des Compiler-Pakete´s ist meist gcc oder egcs.
Sollte der Compiler installiert sein, am Besten die Fehlermeldung von configure zusammen mit dem
betreffenden Auszug aus der config.log im gleichen Verzeichnis hier im Forum posten.
./configure: flex: command not found
Dir fehlt das Programm flex ( Fast Lexical Analyzer Generator ). Flex ist das freie Pendant zu lex und
sollte auf den CDs Deiner Distribution vorhanden sein.
./configure: lex: command not found
siehe flex
Fehlermeldungen bei make
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äufige und meist hier im Forum gefundene Fehlermeldungen und deren Behebung aufgelistet:
make: command not found
make: command not found
Das Programm make ist auf Deinem System nicht installiert.
Dokumentation
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 Tutorials !!
Lizenz
Dieser Beitrag steht unter der "GNU Free Documentation License GFDL" nachzulesen unter:
http://www.gnu.org/copyleft/fdl.html
Lesezeichen