Das Kompilieren von Software aus den Quellen gilt als knifflig. Doch die unter OpenSuse verfügbaren Quellpakete liefern das nötige Know-how frei Haus mit.

Gentoo [1] gilt als sehr komplexe Linux-Distribution, weil sie Software ausschließlich im Quelltext ausliefert, der man erst auf dem eigenen Rechner kompiliert, also in von der CPU ausführbaren Maschinencode übersetzt. Beim Quelltext handelt es sich um von Programmierern geschriebenen Code, zum Beispiel in der Programmiersprache C oder C++. Der Prozessor eines Computers versteht ausschließlich Maschinencode, den ein Mensch kaum nachvollziehen kann (Abbildung 1). Die gängigen Distributionen liefern direkt diesen Maschinencode in Form sogenannter Binärpakete (engl.: Binaries) aus.

Quellcodepakete bieten hinsichtlich der Bibliotheksversionen mehr Flexibilität als vorkompilierte Binärpakete, die nur für eine bestimmte Version einer Linux-Distribution geeignet sind. Außerdem enthalten Binaries zwangsläufig Programmcode, der auf allen gängigen PC-CPUs funktioniert, während man beim Kompilieren auf dem eigenen Rechner den Maschinencode für die verwendete CPU-(Generation) optimieren kann.

Abbildung 1: Links sehen Sie einen Ausschnitt aus dem C-Quellcode von Gimp, rechts den Beginn des Gimp-Binaries in einem Hex-Editor.

Wer genauer hinsieht, stellt fest, dass Quellpakete kein Alleinstellungsmerkmal von Gentoo bilden: Auch das von OpenSuse eingesetzte Paketmanagementsystem RPM [2] kennt sie. Der Unterschied zwischen OpenSuse und Gentoo besteht letztlich nur darin, dass die OpenSuse-Repositories alle Pakete in vorkompilierter Form bereitstellen. Darum greifen nur wenige Anwender auf das vollautomatische Kompilieren auf dem eigenen Rechner zurück.

Auch interessierte OpenSuse-Anwender können jedoch leicht an CPU-optimierte Versionen häufig genutzter Programme gelangen. Auch die Installation brandaktueller Versionen, die noch nicht in den Repositories angekommen sind, lässt sich mithilfe von Quellpaketen schnell umsetzen.

Bastler willkommen

Die Quellcode-Repositories mit den SRC-RPMs sind nach der Installation des OpenSuse-Systems bereits angelegt (Abbildung 2). Da durchschnittliche Anwender sie jedoch nicht benötigen, bleiben sie zunächst inaktiv, sind jedoch schon nach wenigen Klicks einsatzbereit. Dazu wählen Sie im YaST-Modul Software-Repositories nacheinander die beiden mit Source-Repository beginnenden Einträge in der Liste aus und klicken unten im Fenster unter Eigenschaften das Kontrollkästchen Aktiviert an. Für den Paketbau benötigen Sie außerdem noch das standardmäßig nicht vorinstallierte Paket rpm-build.

Abbildung 2: Die offiziellen Repositories für Quellpakete sind in OpenSuse-Systemen von Anfang an vorhanden und warten nur noch auf die Aktivierung durch das Setzen eines Kontrollkästchens.

Für die grafische Paketverwaltung in YaST ändert sich nach dem Aktivieren der SRC-Repositories rein gar nichts, doch das Kommandozeilentool Zypper findet nun zu vielen Paketnamen zusätzlich noch einen Eintrag des Typs Quellpaket (Abbildung 3). Da ein Quellpaket oft mehrere Binärpakete abdeckt, ist das allerdings nicht bei allen Paketen der Fall.

Abbildung 3: Das Kommandozeilenwerkzeug Zypper macht die Quellpakete nach Aktivieren der zugehörigen Repositories zugänglich.

Zum Installieren von Quellpaketen wechseln Sie auf die Kommandozeile. Dort spielt der Befehl sudo zypper si gimp dann beispielsweise alle zum Eigenbau eines Gimp-Pakets erforderlichen Komponenten unter /usr/src/packages/ ein (Abbildung 4). Der Schalter si steht dabei für Source Install und kümmert sich um alle zum Kompilieren nötigen Devel-Pakete, im Fall von Gimp um die 200. Das YaST-Modul Software darf während des Arbeitens mit Zypper auf der Kommandozeile laufen.

Abbildung 4: Der Befehl zypper si gimp hat den Quellcode von Gimp und die für den Bau eines Gimp-Pakets nötige Spec-Steuerdatei eingespielt.

Als Beispiel für das CPU-optimierte Übersetzen eines offiziellen OpenSuse-Pakets nehmen wir uns Gimp vor. Die meisten Bildbearbeitungsoperationen übernimmt in aktuellen Versionen die separate Bibliothek Gegl [3], die wiederum auf die ebenfalls im Gimp-Umfeld entwickelte Bibliothek Babl aufsetzt [4]. Für eine optimale Anpassung des Bildbearbeitungsprogramms an die Hardware des Rechners empfiehlt es sich daher, beide Bibliotheken ebenfalls neu zu kompilieren.

Installieren Sie zur Vorbereitung mit sudo zypper si gimp babl gegl die Quellen zum Bau der Pakete gimp, babl und gegl. Dabei gilt es zu beachten, dass Zypper die Quelldateien systemweit unter /usr/src/packages/ einspielt, einem nur für Root beschreibbaren Verzeichnis. Doch der Paketbau als Administrator kann im Fehlerfall Systemdateien überschreiben und so das System beschädigen.

Um Pakete, wie es dringend geboten ist, als normaler Anwender bauen zu können, verschieben Sie alle Dateien aus den Ordnern SOURCES/ und SPECS/ in /usr/src/packages/ in die gleichnamigen Verzeichnisse unterhalb des gegebenenfalls anzulegenden Verzeichnisses rpmbuild/ in ihrem Home-Verzeichnis (siehe Kasten “Einige Details zum RPM-Paketbau”).

Abbildung 5: Eine Spec-Steuerdatei für den RPM-Paketbau bündelt beschreibende Informationen (links) und Shell-Befehle zum Kompilieren eines Programms aus dem Quellcode (rechts).

Aufgerüscht

Beim Bau von RPM-Paketen bestimmt die Option optflags die dem C- oder C++-Compiler übergebenen Parameter für die CPU-Optimierung. Interessierte können den gegenwärtigen Wert mit rpmbuild --showrc | less inspizieren. Wer sich mit dem Compiler GCC [6] auskennt, sieht, dass die Option -march fehlt. Der Compiler erzeugt also Code, der auf allen x86_64-CPUs (allen PC-CPUs in 64-Bit-Architektur) läuft. Das ändert sich, sobald Sie im Home-Verzeichnis die Datei .rpmrc mit dem Inhalt aus Listing 1 anlegen.

optflags: x86_64 -march=native -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables

Der Inhalt der Datei entspricht den Standard-Optflags unter OpenSuse, mit Ausnahme der Option -march=native zu Beginn. Sie weist den Compiler an, die erzeugten ausführbaren Dateien für die im Rechner verbaute CPU zu optimieren. Das resultierende Programm lässt sich dann sehr wahrscheinlich auf Prozessoren eines anderen Typs nicht ausführen, weshalb diese Optimierung in öffentlichen Paket-Repositories nicht infrage kommt.

Gimp setzt auf Gegl auf, Gegl seinerseits auf Babl. Darum sollten Sie die Pakete in der Reihenfolge Babl – Gegl – Gimp erstellen. Den Anfang macht demnach der in Listing 2 gezeigte Aufruf. Der anschließend über das Konsolenfenster huschende Zeichensalat sollte gegen Ende die drei am Ende des Listings stehenden Zeilen enthalten. Sie geben an, welche Paketdateien Rpmbuild erstellt hat.

$ rpmbuild -bb ~/rpmbuild/SPECS/babl.spec
[...]
Wrote: /home/User/rpmbuild/RPMS/x86_64/libbabl-0_1-0-0.1.72-lp152.1.5.x86_64.rpm
Wrote: /home/User/rpmbuild/RPMS/x86_64/typelib-1_0-Babl-0_1-0.1.72-lp152.1.5.x86_64.rpm
Wrote: /home/User/rpmbuild/RPMS/x86_64/babl-devel-0.1.72-lp152.1.5.x86_64.rpm

Danach installieren Sie sie alle mit sudo zypper in ~/rpmbuild/RPMS/x86_64/RPM-Paket. Zypper meldet bei jedem Paket Fehler beim Überprüfen der Signatur [6-Datei ist unsigniert]. Bei selbstgebauten Paketen stellt der fehlende Herkunftsnachweis jedoch kein Sicherheitsproblem dar, weswegen Sie ihn für jedes Paket mit [I] ignorieren. Führen Sie Rpmbuild nun für gegl.spec im SPECS/-Ordner aus, und installieren Sie mit Zypper ebenfalls alle per Wrote:**[…] vermeldeten RPMs. Genauso gehen Sie zum Abschluss für gimp.spec vor.

Das Kompilieren von Gimp nimmt je nach Leistung des Rechners einige Zeit in Anspruch, doch auf aktuellen Computern ist das eher eine Frage von Minuten als von Stunden. Dafür läuft auf Ihrem System danach eine optimierte Version des Bildbearbeitungsprogramms, die der von Gentoo (einer an erfahrene Anwender ausgerichteten Distribution) um nichts nachsteht.

Alternativangebote

Neben der hohen Leistung sticht Gentoo dadurch heraus, dass Anwender oft zwischen mehreren Versionen eines Pakets wählen können, zum Beispiel einer stabilen und einer Beta-Version. Diese ebenfalls durch das Kompilieren auf dem Anwenderrechner erkaufte Flexibilität bieten die SRC-RPMs auch unter OpenSuse.

Allerdings handelt es sich dabei um kein von den OpenSuse-Entwicklern getestetes Vorgehen: Manchmal klappt das Erstellen einer alternativen Paketversion spontan nach dem bloßem Verändern einer Versionsnummer in der erwähnten Spec-Datei (siehe Zeile 22 in der linken Hälfte von Abbildung 5).

Gelegentlich ist aber auch das volle Expertenwissen der OpenSuse-Entwickler gefragt, um ein Paket aufzufrischen. Dann funktionieren die in der Spec-Datei festgehaltenen Befehle zum Kompilieren für die neue Version nicht mehr, oder es kommt zu Kompatibilitätsproblemen mit den auf dem System vorliegenden Bibliotheken. Die Liste der potenziellen Probleme ist lang. Gelegentlich müssen sich nicht professionelle Anwender hier mit einem Misserfolg abfinden.

Am erfolgversprechendsten ist es, SRC-RPM-Pakete vom OpenSuse Build Service herunterzuladen: Dort finden Sie Quellpakete, die zumindest auf einem ähnlichen OpenSuse-System erfolgreich kompilieren (Abbildung 6). Eine Garantie, dass es auch in einer älteren Umgebung funktioniert – oder einer neueren, wenn Sie eine ältere Version als die des offiziellen Pakets herunterladen – gibt es aber auch hier nicht. Immerhin liegen die Erfolgschancen deutlich höher. Der Build Service dient dabei nur als Lieferant von Quellpaketen; mit seiner Bedienung für den Paketbau brauchen Sie sich nicht auseinanderzusetzen. Sie benötigen auch keinen Build-Service-Account.

Abbildung 6: Der Expert Download für “Tumbleweed” beim Build-Service-Suchergebnis für Gimp öffnet eine Seite, auf der Sie nach Klick auf Binärpakete direkt herunterladen je nach Bedarf Binaries für 32- und 64-Bit-CPUs sowie ein Quell-RPM herunterladen.

Auch hier wählen wir wieder das Grafikprogramm Gimp als Beispiel. Wie bereits beim Rekompilieren für die CPU-Optimierung benötigen wir dabei außer dem Paket gimp selbst noch die Bibliotheken babl und gegl, die in zueinander kompatiblen Versionen vorliegen müssen. OpenSuse “Leap” 15.2 liefert Gimp in Version 2.10.12, “Tumbleweed” dagegen in der beim Verfassen dieses Artikels neuesten von den Gimp-Entwicklern freigegebenen Ausgabe 2.10.20.

Aufgefrischt

“Tumbleweed”-Pakete lassen sich unter OpenSuse “Leap” in aller Regel nicht installieren, doch häufig klappt das Kompilieren von “Tumbleweed”-Quellpaketen. Für eine taufrische Gimp-Version suchen Sie auf https://software.opensuse.org nach Gimp, Babl und Gegl. Um die Source-RPMS herunterzuladen, klicken Sie jeweils in der Zeile für openSUSE Tumbleweed auf Expert Download und auf der nächsten Seite auf Binärpakete direkt herunterladen. Bei den auf .src.rpm endenden Downloads handelt es sich um die gesuchten Quellpakete.

Haben Sie die Software als SRC-RPMs via Webbrowser heruntergeladen, dann müssen Sie den Quellcode nicht erneut mit zypper si installieren. Allerdings liefert der Zypper-Source-Install-Befehl auch die rund 200 Devel-Pakete, ohne die sich Gimp nicht kompilieren lässt. Die holen Sie sich hier über das Kommando zypper si -d gimp, wobei der Schalter -d nur die Devel-Pakete einspielt, nicht aber die schon heruntergeladenen Gimp-Quelltexte.

Da die SRC-RPMs eine andere Gimp-Version enthalten als die OpenSuse-Repositories, von denen Zypper beim si-Befehl ausgeht, kann es passieren, dass trotzdem noch einige für den Paketbau nötige Abhängigkeiten fehlen. Rpmbuild meldet dies gegebenenfalls sofort nach dem Aufruf (Listing 3). Direkt angegebene Pakete installieren Sie einfach nach. Bei Meldungen der Form pkgconfig(...) (Zeile 6 und 7) suchen Sie im Paketmanager nach dem Namen in Klammern und installieren die dabei gefundenen Devel-Pakete.

[...]
error: Failed build dependencies:
        libjpeg-devel is needed by gimp-2.10.20-my_01.x86_64
        libmng-devel is needed by gimp-2.10.20-my_01.x86_64
        libwmf-devel >= 0.2.8 is needed by gimp-2.10.20-my_01.x86_64
        pkgconfig(gtk+-2.0) >= 2.24.10 is needed by gimp-2.10.20-my_01.x86_64
        pkgconfig(pango) >= 1.29.4 is needed by gimp-2.10.20-my_01.x86_64
        python-gtk-devel >= 2.10.4 is needed by gimp-2.10.20-my_01.x86_64

SRC-RPMs brauchen Sie vor dem Kompilieren nicht zu installieren: Der Aufruf rpmbuild --rebuild Paket.src.rpm startet den Paketbau, ohne dass dazu der Quellcode oder eine Spec-Datei separat in Erscheinung treten. Nur, wenn Sie die Spec-Datei editieren möchten, installieren Sie die SRC-RPMs mit rpm -ivh Paket.src.rpm, und zwar als normaler Anwender. Dann landen die Quelldateien nicht im systemweiten Verzeichnis /usr/src/packages/, sondern direkt in rpmbuild/ in Ihrem Home-Verzeichnis.

Beim Kompilieren der SRC-RPMs vom Build Service erscheinen auf der Konsole dieselben Meldungen wie beim Verarbeiten der mit zypper si installierten Spec-Dateien. Zeilen wie Wrote: /home/User/rpmbuild/RPMS/x86_64/[...].x86_64.rpm kündigen auch hier an, dass Rpmbuild Pakete gebaut hat, die nun unter rpmbuild/RPMS/x86_64/ oder rpmbuild/RPMS/noarch (im Fall von architekturunabhängigen (Sprach-)Paketen) liegen.

Wie schon beim CPU-optimierten Rekompilieren der Original-OpenSuse-Pakete verarbeiten Sie auch hier zuerst die Babl-Quellpakete, dann Gegl und zuletzt Gimp selbst. Die erstellten Pakete installieren Sie jeweils mit sudo zypper install Pfad/RPM, bevor Sie zur nächsten Komponente übergehen.

Fazit

Das Kompilieren von SRC-RPMs gelingt einfach und ohne viel Hintergrundwissen. Darum lohnt sich ein Versuch auf jeden Fall, auch wenn der Erfolg beim Kompilieren von noch nicht in den Standard-Repositories enthaltenen neueren Software-Versionen nicht garantiert ist. Im Erfolgsfall erhalten Sie jedoch perfekt für Ihr System optimierte Programme.