Slackware Multilib: 32-Bit-Kompatibilität auf Slackware64

23.10.2026 · Zuletzt aktualisiert: 07.09.2026 · 7 Min. Lesezeit

Slackware64 ist eine konsequent auf x86_64 ausgerichtete 64-Bit-Distribution. Das bedeutet allerdings nicht, dass 32-Bit-Software grundsätzlich ausgeschlossen ist. Slackware64 ist vielmehr multilib-ready: Die Verzeichnisstruktur und wesentlichen Voraussetzungen sind so ausgelegt, dass eine 32-Bit-Kompatibilitätsschicht nachgerüstet werden kann.

Genau hier setzt Multilib an.

Multilib erweitert ein Slackware64-System so, dass es 64-Bit- und 32-Bit-Programme parallel ausführen und – mit den entsprechenden Werkzeugen – auch kompilieren kann. Für Slackware 15.0 ist das insbesondere für Wine, ältere proprietäre Software, bestimmte Spiele und andere Programme interessant, die noch 32-Bit-Komponenten benötigen.

Das Problem: 64 Bit allein reicht nicht immer

Ein reines Slackware64 15.0 enthält 64-Bit-Programme und Bibliotheken. Die wesentlichen Bibliothekspfade sind:

/lib64
/usr/lib64

Ein 32-Bit-ELF-Programm erwartet dagegen seine Laufzeitbibliotheken typischerweise unter:

/lib
/usr/lib

Slackware64 ist deshalb so strukturiert, dass beide Bibliothekswelten nebeneinander existieren können. Im Auslieferungszustand fehlen jedoch die 32-Bit-Komponenten.

Ein 32-Bit-Programm kann deshalb beispielsweise mit einer Fehlermeldung wie

No such file or directory

enden, obwohl die eigentliche ausführbare Datei vorhanden ist. Häufig fehlt in diesem Fall nicht das Programm selbst, sondern der für das 32-Bit-ELF-Programm benötigte Dynamic Loader beziehungsweise eine seiner Bibliotheken.

Multilib ergänzt genau diese fehlende Infrastruktur.

Was Multilib technisch verändert

Die Multilib-Lösung für Slackware stammt im Wesentlichen aus dem Umfeld von Eric Hameleers (AlienBOB).

Das Konzept besteht aus zwei Teilen.

Teil 1: multilib-fähige glibc und GCC

Zunächst werden die offiziellen Slackware-Pakete für

glibc
gcc

durch Multilib-Varianten ersetzt.

Die Multilib-Version von glibc kann sowohl 64-Bit- als auch 32-Bit-Programme unterstützen. Die entsprechende GCC-Toolchain kann zusätzlich 32-Bit-Code erzeugen.

Für Slackware 15.0 enthält das Multilib-Repository beispielsweise Pakete wie:

gcc-11.2.0_multilib-x86_64-...
gcc-g++-11.2.0_multilib-x86_64-...
aaa_glibc-solibs-2.33_multilib-x86_64-...
glibc-2.33_multilib-x86_64-...

Der aktuelle Stand des Slackware-15.0-Multilib-Repositories wird weiterhin gepflegt; das Verzeichnis enthält beispielsweise aktuelle Paketlisten und Checksummen.

Teil 2: 32-Bit-Kompatibilitätsbibliotheken

Damit ist die Arbeit noch nicht abgeschlossen.

Ein 32-Bit-Programm benötigt schließlich auch Bibliotheken wie beispielsweise:

libc.so.6
libstdc++.so.6
libGL.so
libX11.so

Diese Bibliotheken stammen aus der 32-Bit-Version von Slackware.

Sie werden allerdings nicht einfach als normale 32-Bit-Pakete installiert. Das wäre problematisch, weil ein Paket wie mesa, zlib oder SDL2 auch Dateien enthalten kann, die mit den bereits installierten 64-Bit-Dateien kollidieren.

Stattdessen werden daraus sogenannte compat32-Pakete erzeugt.

Beispielsweise:

mesa

wird zu:

mesa-compat32

Die 32-Bit-Bibliotheken landen dann unter /lib beziehungsweise /usr/lib, während die 64-Bit-Varianten unter /lib64 und /usr/lib64 verbleiben.

Damit entsteht eine saubere parallele Struktur:

flowchart TD
    A[Slackware64] --> B["64 Bit"]
    A --> C["32 Bit"]
    B --> D["/lib64<br/>/usr/lib64"]
    C --> E["/lib<br/>/usr/lib"]

Genau diese Trennung ist ein zentraler Bestandteil des Multilib-Konzepts.

Warum werden die 32-Bit-Pakete nicht einfach installiert?

Das ist ein wichtiger Punkt bei Slackware.

Angenommen, man hätte:

x86_64/mesa-...
i586/mesa-...

und würde beide mit installpkg installieren.

Dann hätte die Paketverwaltung zwei Pakete mit demselben Namen. Noch schlimmer: Enthält das 32-Bit-Paket ausführbare Dateien unter /usr/bin, könnten diese die 64-Bit-Versionen überschreiben.

Das würde das System beschädigen.

Deshalb werden aus den 32-Bit-Paketen Kompatibilitätspakete erstellt. Das Suffix

-compat32

macht deutlich, dass es sich um die 32-Bit-Kompatibilitätsschicht eines 64-Bit-Systems handelt.

compat32-tools

Für diese Aufgabe gibt es das Paket compat32-tools.

Es stellt unter anderem Werkzeuge bereit, mit denen sich normale Slackware-32-Bit-Pakete in installierbare -compat32-Pakete umwandeln lassen.

Ein wichtiges Werkzeug ist:

convertpkg-compat32

Es nimmt beispielsweise ein 32-Bit-Slackware-Paket

mesa-...-i586-...

und erzeugt daraus:

mesa-...-compat32-...

Dieses kann anschließend auf Slackware64 installiert werden.

Für die massenhafte Konvertierung gibt es außerdem:

massconvert32.sh

Damit lässt sich ein kompletter Satz von 32-Bit-Slackware-Paketen in compat32-Pakete umwandeln.

AlienBOB stellt allerdings bereits eine Sammlung fertig konvertierter Pakete im Verzeichnis

slackware64-compat32/

bereit. Dadurch muss man nicht zwangsläufig jedes Paket selbst konvertieren.

Was bringt Multilib in der Praxis?

Der bekannteste Anwendungsfall ist Wine.

Wine kann auf einem 64-Bit-System zwar 64-Bit-Windows-Programme ausführen. Zahlreiche ältere Windows-Anwendungen und Spiele sind jedoch 32-Bit-Anwendungen und benötigen entsprechende 32-Bit-Linux-Bibliotheken.

Mit Multilib kann beispielsweise eine Anwendungskette wie diese funktionieren:

flowchart TD
    A["Windows-Programm"] --> B[Wine]
    B --> C["32-Bit Linux ABI"]
    C --> D["compat32 libraries"]
    D --> E["Linux Kernel / Hardware"]

Auch die Steam-Unterstützung auf Slackware64 profitiert von Multilib. AlienBOB nennt Multilib ausdrücklich als Grundlage für die Unterstützung der Steam-Plattform auf Slackware64.

Daneben gibt es weitere mögliche Einsatzgebiete:

• ältere proprietäre Linux-Software
• alte Spiele
• 32-Bit-Browser-Plugins oder Laufzeitumgebungen
• ältere Entwicklungsumgebungen
• Programme, deren Hersteller keine 64-Bit-Version bereitstellt
• das Kompilieren eigener 32-Bit-Software

Multilib bedeutet nicht “32-Bit-Slackware auf 64-Bit”

Das ist ein wichtiger konzeptioneller Unterschied.

Nach der Einrichtung bleibt das System:

Slackware64 15.0

Die normalen Programme und Systembibliotheken sind weiterhin 64 Bit.

Multilib fügt lediglich eine zusätzliche ABI-Schicht hinzu:

flowchart TD
    A["Slackware64 15.0"] --> B["64-Bit native"]
    A --> C["32-Bit compat32"]
    B --> D["/lib64<br/>/usr/lib64"]
    C --> E["/lib<br/>/usr/lib"]

Man verwandelt Slackware64 also nicht in ein 32-Bit-System. Man macht es zu einem System, das beide ABIs gleichzeitig unterstützt.

Multilib und Slackware-Paketverwaltung

Hier wird es besonders interessant.

Das Multilib-Repository enthält Pakete, die teilweise Alternativen zu offiziellen Slackware-Paketen darstellen.

Das betrifft bei Slackware 15.0 insbesondere:

gcc
glibc

Die Multilib-Versionen müssen Vorrang vor den entsprechenden offiziellen Slackware-Paketen haben.

Genau dafür ist PKGS_PRIORITY in slackpkg+ gedacht.

Eine typische Konfiguration sieht beispielsweise konzeptionell so aus:

PKGS_PRIORITY=( multilib ... )

und das Repository wird als

MIRRORPLUS['multilib']=...

eingetragen.

Dadurch weiß slackpkg+, dass die Multilib-Varianten von gcc und glibc gegenüber den gleichnamigen Slackware-Paketen bevorzugt werden sollen.

Das ist einer der Fälle, in denen slackpkg+ und Multilib sehr gut zusammenspielen.

Updates sind besonders wichtig

Multilib sollte man nicht einmal installieren und danach vergessen.

Wenn Slackware beispielsweise eine neue Version von glibc oder GCC veröffentlicht, muss geprüft werden, welche Multilib-Version dazu gehört.

Für Slackware 15.0 ist das besonders relevant, weil die Multilib-Versionen von GCC und glibc Teil der Multilib-Infrastruktur sind.

Bei System-Upgrades sollte man deshalb immer darauf achten, dass:

Slackware gcc/glibc

und

Multilib gcc/glibc

nicht versehentlich vermischt werden.

SlackDocs weist ausdrücklich darauf hin, dass Multilib-Pakete beim Upgrade auf eine neue Slackware-Version durch die passenden Pakete der neuen Version ersetzt werden müssen.

Slackware 15.0 ist dabei ein Sonderfall

Ein interessanter historischer Punkt:

Slackware 15.0 ist laut aktueller Multilib-Dokumentation die letzte Slackware-Version, für die separate Multilib-Versionen von GCC und glibc benötigt werden.

Das macht die Multilib-Konfiguration bei 15.0 etwas spezieller als bei neueren Entwicklungsständen.

Für eine bestehende Slackware64-15.0-Installation sollte man daher nicht blind Anleitungen für -current übernehmen.

Ein typischer Aufbau

Ein Slackware64-15.0-Desktop mit Multilib könnte konzeptionell so aussehen:

flowchart TD
    A["Slackware64 15.0"] --> B["offizielles Slackware"]
    B --> B1["64-Bit glibc"]
    B --> B2["64-Bit GCC"]
    B --> B3["64-Bit Libraries"]
    A --> C[Multilib]
    C --> C1["multilib glibc"]
    C --> C2["multilib GCC"]
    C --> C3["weitere Multilib-Pakete"]
    A --> D[compat32]
    D --> D1[libc]
    D --> D2["libstdc++"]
    D --> D3[Mesa]
    D --> D4[SDL]
    D --> D5["X11 Libraries"]
    D --> D6["weitere 32-Bit Libraries"]

Darüber kann dann beispielsweise Wine laufen:

flowchart TD
    A[Wine] --> B["64-bit Windows program"]
    A --> C["32-bit Windows program"]
    B --> D["Linux ABI"]
    C --> D
    D --> E["64-bit libraries"]
    D --> F["32-bit compat32"]

Muss man Multilib unbedingt installieren?

Nein.

Wenn ausschließlich aktuelle 64-Bit-Linux-Software eingesetzt wird, bringt Multilib wenig.

Für einen Server kann ein reines Slackware64 sogar die sinnvollere Lösung sein:

flowchart TD
    A["weniger Pakete"] --> B["weniger Komplexität"]
    B --> C["weniger Wartungsaufwand"]

Für einen Desktop sieht die Situation anders aus. Sobald Wine, Steam oder ältere proprietäre Software relevant werden, kann Multilib einen erheblichen praktischen Nutzen haben.

Multilib ist typisch Slackware

Das Interessante an der Lösung ist weniger die technische Idee selbst als die Art, wie Slackware sie umsetzt.

Slackware hätte theoretisch auch ein komplettes Multilib-System ausliefern können.

Stattdessen lautet die Philosophie:

Slackware64 bleibt zunächst ein reines 64-Bit-System. Wer 32-Bit-Unterstützung benötigt, aktiviert sie bewusst.

Die Distribution liefert dafür die Voraussetzungen und die Infrastruktur. Die Entscheidung liegt beim Administrator.

Das hat einen wichtigen Nebeneffekt: Ein minimalistisches Slackware-System bleibt tatsächlich minimal.

Wer Multilib braucht, bekommt es.

Wer es nicht braucht, muss weder 32-Bit-Bibliotheken noch zusätzliche Toolchain-Komponenten installieren.

Fazit

Multilib ist keine zweite Slackware-Installation, sondern eine zusätzliche ABI-Kompatibilitätsschicht für Slackware64.

Die Architektur lässt sich auf drei Ebenen reduzieren:

flowchart TD
    A["1. Multilib glibc + GCC"] --> B["2. 32-Bit compat32 libraries"]
    B --> C["3. 32-Bit Anwendungen"]

Die 64-Bit-Welt bleibt dabei vollständig erhalten.

Für Slackware64 15.0 ist die von AlienBOB bereitgestellte Multilib-Infrastruktur besonders relevant. Das aktuelle Repository für 15.0 wird weiterhin gepflegt und stellt sowohl die Multilib-Systempakete als auch einen Bestand konvertierter compat32-Pakete bereit.

Wer Slackware 15.0 als Desktop-System betreibt und beispielsweise Wine, Steam oder ältere 32-Bit-Software einsetzen möchte, bekommt mit Multilib eine sehr saubere Lösung, die gleichzeitig gut zur traditionellen Slackware-Philosophie passt: Das System installiert nur das, was der Administrator bewusst benötigt.