Unter Linux kann man viele Tolle Dinge tun, wenn man selber Software kompilieren kann. Und zwar nicht nur selber geschriebene Software, sondern auch all die OpenSource Software die für Linux frei über das Internet erhältlich ist. Hier erkläre ich wie das geht!
Inhaltsverzeichnis:
Einführung
Die meiste Software für Linux ist in C oder C++ programmiert. Generell nicht kompiliert werden muss natürlich Software die in einer Script-Sprache wie Ruby oder Perl geschrieben ist. Die Interpreter dieser Script-Sprachen sind aber in der Regel ebenfalls in C/C++ programmiert. Übrig bleibt noch einiges an Software was in Java oder anderen Compiler-Sprachen geschrieben ist. Hier soll aber aus den genannten Gründen erst mal alles was mit C/C++ programmiert ist abgedeckt werden. Nur ein paar wenige Beispiele dafür sind:
- Geany: Texteditor und kleine und schnelle integrierte Entwicklungsumgebung (IDE)
- GIMP: ein und womöglich sogar »das« Bildbearbeitungs-Programm für Linux
- Pidgin: Multi-Messenger-Client für bspw. Jabber oder Facebook-Chat
- node.js: Software zur server-seitigen Java-Script-Programmierung
- AbiWord: Textverarbeitung-Programm ähnlich Word oder Libre-/OpenOffice Writer
All diese Programme habe ich schon einmal selber kompiliert. Und mit Ausnahme von GIMP, wo für die babl- und gegl-Bibliotheken noch ein paar Kniffe notwendig sind (siehe unten), lassen sie sich wirklich einfach mit dem “configure, make, make install” Dreisatz kompilieren.
Gründe für das Selber Kompilieren
Die drei Haupt-Gründe warum man als fortgeschrittener Linux-Nutzer und erst recht als Informatiker zumindest lernen sollte Software selber zu kompilieren sind folgende:
- Mehr Software: Über die Software hinaus welche von der verwendeten Linux-Distribution (openSUSE, Ubuntu, Debian, etc.) über das Paket-Management angeboten wird, gibt es noch unzählige weitere Software für Linux im Internet. Manche davon wird fertig kompiliert zum Download angeboten (z.B. Eclipse) andere hingegen nicht. Außerdem kann man durch das selber Kompilieren auch an neuere Software-Versionen kommen, die über das Paketmanagement noch nicht angeboten werden.
- Neuere Software: Insbesondere Beta-Versionen sind oft nur als Quellcode erhältlich. Ganz einfach aus dem Grund, weil die Entwickler dieser Software eh die ganze Zeit mir dem Quellcode arbeiten. Und aufgrund der schnellen Weiterentwicklung im Beta-Stadium lohnt es meistens auch kaum extra kompilierte Versionen zum Download bereitzustellen, da diese schnell wieder veraltet sind. Wer also selber kompilieren kann, kann auch tolle neue Software mit Beta-Funktionen früher ausprobieren.
- Schnellere Software: Wenn man Software selber kompiliert, kann sie dabei speziell für den Computer auf dem sie laufen soll kompiliert werden. Vorkompilierte Software aus dem Paketmanagement ist so kompiliert, dass sie möglichst auf allen Computern arbeitet. Spezialfunktionen der CPU wie SSE4 werden daher meist nicht genutzt. Wenn man Software jedoch selber kompiliert kann man das ändern und die kompilierte Software läuft dann mit bspw. SSE4 evtl. deutlich schneller (ist aber nicht immer so). Der Aufwand hierfür lohnt sich meiner Meinung nach allerdings erst, wenn man mehrere (10 oder mehr) Computer mit identischer CPU hat und diese über einen längeren Zeitraum intensiv mit der Software genutzt werden sollen. Ein Beispiel hierfür könnte Video-Kodierung sein.
- Mehr Sicherheit: Wenn man vorkompilierte Software installiert kann man nie sicher sein was diese wirklich tut. Selbst wenn die Software OpenSource ist kann sie doch trotzdem nicht wirklich aus dem Quellcode kompiliert worden sein der mitgeliefert wurde. Erst wenn man die Software selber kompiliert kann man wirklich (halbwegs) sicher sein was die Software tut und was nicht. Um ganz sicher zu wissen was die Software tut muss man dazu noch den Quellcode komplett durchlesen und ihn genau verstehen, was oftmals zu viel Arbeit ist. Trotzdem bietet das selber Kompilieren eine gewisse Sicherheit, da der Quellcode immer wieder von verschiedensten Leuten gelesen wird. Und bei Problemen im Nachhinein kann ebenfalls kontrolliert werden was in der Software genau passiert.
- Noch mehr Sicherheit in Wichtigen Bereichen: Außerdem kann es gerade für Unternehmen in sicherheitskritischen Bereichen tatsächlich Sinn machen, vor Einsatz einer Software wirklich erst mal den Quellcode komplett zu kontrollieren. Da sitzt dann ein Mitarbeiter vielleicht einen Monat aber länger dran. Dafür kann man nachher aber mit fast 100% Sicherheit ausschließen, dass in der Software fremde Spionage-Module sind. Vorrausgesetzt, man kompiliert die Software dann auch selber aus dem kontrollierten Quellcode.
- Probleme finden und beheben: Das ist jetzt schon fast die Königsklasse und im Gegensatz zu dem vorherigen Punkt (kompletten Quellcode durchlesen) auch wieder etwas weniger Arbeit. Sollte eine Software Fehler zeigen, oder gar sicherheitskritische Lücken, ist man nicht darauf angewiesen auf der Hersteller den es evtl. gar nicht mehr gibt und ein Update von diesem zu warten. Man kann den Fehler mit entsprechendem KnowHow und etwas Zeit selber im Quellcode beheben und kompiliert die Software danach einfach neu.
- Eigene Änderungen: Die Königsklasse! Wenn einem jemals eine Funktion in einer Software fehlte und vor allem wenn man sich dabei doch immer gedacht hat “Das ist doch nur eine Kleinigkeit”. So kann man es selber tun! Ich habe das selber schon mehrmals gemacht. Das eine mal war es z.B. ein Zoom-Button der schlecht gezoomt hat, ein anderes mal ein PDF-Programm das mir verboten hat Text aus einem geschützten PDF zu kopieren. Besonders sinnvolle Änderungen werden dann auch oftmals gerne vom Entwickler-Team übernommen.
- Ein Fork: Das ist jetzt nicht unbedingt die Kaiserklasse, denn ein Fork will gut überlegt sein. Manchmal ist es aber unumgänglich sich von alten Entwicklungsstrukturen zu lösen und ein neues Projekt auf dem existierenden SourceCode zu starten. Ein Beispiel dafür ist die Abspaltung LibreOffice vom kaum noch weiterentwickelten OpenOffice. Des weiteren kann ein nahe am original betriebener Fork eine Möglichkeit für Organisationen sein, eine Software für ihre eigenen Zwecke besser anzupassen.
Los geht’s!
Für das Kompilieren von C/C++ Software unter Linux gibt es verschiedene Systeme. Bekannt sind qmake und cmake. Aber am weitesten verbreitet ist wohl der “configure, make, make install” Dreisatz! Dieser soll hier zuerst am einfachen Beispiel von Geany und dann am etwas komplexeren Beispiel einer GIMP-Entwickler-Version (im Prinzip eine Beta) gezeigt werden.
Einstieg mit Geany
ANMERKUNG: Ich habe hier erst mal nur ein paar Notizen rein kopiert. Irgendwann demnächst wird das noch etwas leserlicher.
1.
geany-1.23.1.tar.bz2 (Stand 5.7.2013) von hier herunterladen: http://www.geany.org/Download/Releases
2.
Entpacken, z.B. von der Konsole aus mit: tar xvf geany-1.23.1.tar.bz2
3.
Einen Ordner anlegen in den Installiert werden soll. Z.B. /home/BENUTZER/opt/geany/
4.
Über das Paketmanagement der Distribution die folgenden Pakete installieren: make gcc
5.
Konsole in dem Ordner mit den entpackten Dateien aus geany-1.23.1.tar.bz2 öffnen und folgenden Befehl eingeben: ./configure --prefix=/home/BENUTZER/opt/geany/
Wahrscheinlich kommt es dabei zu Fehlern folgender Art: No package 'gtk+-2.0' found
In diesem Fall muss man das Paketmanagement seiner Distribution starten und z.B. bei dieser Meldung dort nach “gtk” suchen. Es gibt dann verschiedene Pakete auf die diese Suche zutrifft. Für das Kompilieren werden in der Regel immer die Pakete mit der Endung “-devel” oder “-dev” benötigt. In diesem Fall ist es auf openSUSE 12.3 bspw. das Paket “gtk2-devel”. Nachdem man dieses Paket dann installiert hat startet man nochmals den selben Befehl. Das wird so lange wiederholt, bis keine Fehler mehr kommen und “configure” mit der Meldung “Configuration is done OK.” abschließt.
6.
Das eigentliche Kompilieren wird mit folgenden Befehl gestartet.
make
Etwas schneller geht es auf Computern mit mehreren Kernen folgendermaßen. Hinter -j muss dabei die Anzahl der Prozessorkerne stehen (hier beispielshalber 4).
make -j4
7.
Das fertig kompilierte Programm wird mit diesem Befehl nach “/home/BENUTZER/opt/geany/” installiert
make install
und mit diesem Befehl gestartet
/home/BENUTZER/opt/geany/bin/geany
Für Fortgeschrittene mit GIMP
ANMERKUNG: Ich habe hier erst mal nur ein paar Notizen rein kopiert. Irgendwann demnächst wird das noch etwas leserlicher.
ANMERKUNG: “autogen” ruft intern “configure” auf.
GIMP-Entwickler-Version (Beta)
1. “git” installieren
2. Die Entwickler-Version von GIMP brauch oft eine sehr aktuelle GLIB-Version. Falls diese über das Paketmanagement nicht erhältlich ist, kann sie hier heruntergeladen und dann ebenfalls selber kompiliert werden (auch mit ./autogen).
http://ftp.gnome.org/pub/gnome/sources/glib/?C=N;O=D
export PREFIX=/home/BENUTZER/opt/gimp/ mkdir $PREFIX cd $PREFIX mkdir build cd build git clone git://git.gnome.org/babl git clone git://git.gnome.org/gegl git clone git://git.gnome.org/gimp export PATH="$PREFIX/bin:$PATH" export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH" export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH" export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS" cd "$PREFIX"/build/babl* ./autogen.sh --prefix="$PREFIX" make -j4 make install cd "$PREFIX"/build/gegl* ./autogen.sh --prefix="$PREFIX" make -j4 make install cd "$PREFIX"/build/gimp* ./autogen.sh --prefix="$PREFIX" make -j4 make install
Wer lieber die aktuelle stabile Version von GIMP verwenden will, kann diese sowie die zugehörige babl- und gegl-Bibliothek hier herunterladen (Stand 07.07.2013). Das Herunterladen mit git fällt dafür dann weg.
ftp://ftp.gimp.org/pub/
ftp://ftp.gimp.org/pub/gimp/v2.8/gimp-2.8.6.tar.bz2
ftp://ftp.gimp.org/pub/babl/0.1/babl-0.1.10.tar.bz2
ftp://ftp.gimp.org/pub/gegl/0.2/gegl-0.2.0.tar.bz2
Weitere Infos: http://www.gimp.org/source/howtos/gimp-git-build.html
Exkurs: SumatraPDF unter Windows kompilieren
Hierzu gibt es einen eigenen Artikel: SumatraPDF ohne DRM-Beschränkungen