Endlich da, aber eigentlich zu spät: Multiarch-Support

Man glaubt es kaum, aber es gibt einige Sachen, die unter Ubuntu nicht perfekt implementiert sind. Manchmal sind andere Systeme besser ;-). Die parallele Unterstützung von Prozessor-Architekturen auf einem System zum Beispiel. Einige Architekturen, wie x86_64, sind in der Lage, über einen Kompatibilitätsmodus alte x86-Programme auszuführen, ohne das eine Neuübersetzung erforderlich wäre. Andere, wie Itanium, schaffen das zumindest durch Hardware-Emulation.

Jedoch muss auch das Betriebssystem dieses Feature unterstützen. Windows kann es, Mac OS X kann es, und Ubuntu kann es eigentlich auch. Allerdings war es unter Ubuntu (und unter Debian, allgemein mit dpkg) bisher nicht sehr einfach, ein für x86 gedachtes Paket einfach so unter x86_64 zu installieren. Nun, wenn es nur *ein* Paket war, dann konnte man es mit der Option –force-architecture trotzdem installieren. Aber normalerweise hängen Pakete von anderen Paketen ab (z.B shared libraries), und ein 32-Bit-Programm benötigt natürlich 32-Bit-Bibliotheken. Die restlichen 64-Bit-Programme benötigt aber 64-Bit-Bibliotheken, womit man von einigen Bibliotheken beide Varianten installieren müsste. Dies gibt sowohl auf der Ebene des Dateisystems als auch auf der des Paketmanagers Probleme.

In der Vergangenheit gab es mehrere Hacks, um dieses Problem zu umgehen. Manche richteten sich ein 32-Bit-chroot ein und ließen ihre 32-Bit Software darin laufen. Die Maintainer paketierten 32-Bit-Bibliotheken für 64-Bit-Systeme, etwa in dem Sammelpaket ia32-libs (oder einzelne lib32*-Pakete), die an andere Orte wie /lib32 und /usr/lib32 installiert wurden. Die – meist proprietären – 32-Bit-Anwendungen wurden dann ebenfalls neu paketiert, um diese Bibliotheken nutzen zu können. Für Browser-Plugins wie Flash wurden Wrapper geschrieben, um 32-Bit-Plugins in einem 64-Bit-Browser benutzen zu können. Aber eine richtige Lösung war das nicht.

Unter Windows war es noch nie ein Problem, 32-Bit-Anwendungen unter 64-Bit-Windows zu installieren. Das ist sogar eher die Regel als die Ausnahme, Software-Hersteller beschäftigen sich nur mit 64-Bit, wenn es signifikante Vorteile bringt, ansonsten wäre es nur sinnlose Ressourcen-Verschwendung, die Anwendung läuft auch als 32-Bit-Binary unter 64-Bit. Man installiert die Anwendung einfach, ohne sich um die Architektur zu kümmern. Und Apple? Die haben schon mehrere Architekturwechsel hinter sich, von 68k auf PowerPC, x86 und schließlich x86_64. Durch Emulation (getauft Rosetta) konnte man die alten Anwendungen auf der neuen Architektur weiterverwenden, sogar Code für mehrere Architekturen in einer Datei verpacken.

Unter Debian und Ubuntu wird all das jetzt mit dem neuen Multiarch-Support möglich. Ab Ubuntu Oneiric und Debian Wheezy wird er mit dabei sein. Multiarch ermöglicht es, Anwendungen und Bibliotheken zu installieren, die für eine Architektur gebaut wurden, die entweder als Fallback von der eigenen Architektur oder von einem Emulator (wie QEMU) unterstützt wird.

Auf Dateisystem-Ebene bedeutet das: Bibliotheken werden nicht mehr einfach nach /lib bzw. /usr/lib installiert, sondern mit architekturspezifischen Präfixen, etwa /lib/i386-linux-gnu oder /usr/lib/x86_64-linux-gnu – gleiches gilt für Header-Dateien. Dadurch kommen sich die Bibliotheken nicht mehr in Konflikt und können parallel existieren. /lib/32, /usr/lib32, /lib64 und /usr/lib64 fallen weg. Anwendungen, Build-Systeme und Compiler müssen natürlich diese Features unterstützen.

Auch der Paketmanager muss gleichzeitig Pakete mehrerer Architekturen verwalten können. Im Augenblick kann in der Datei /etc/dpkg/dpkg-cfg.d/multiarch eingestellt werden, welche Architekturen neben der Nativen berücksichtet werden sollen. Synaptic zeigt dann die fremden Pakete nach dem Schema <paketname>:<architekturname>, also zum Beispiel adobe-flashplugin:i386 an. Das Software-Center von Ubuntu zeigt jedes Programm nur einmal an und nimmt die native Variante wenn möglich, ansonsten eben das architekturfremde Paket.

In den Meta-Daten der Pakete kann über die Option Multi-Arch angegeben werden, wie es sich auf fremden Architekturen verhalten soll.

  • same bedeutet, dass es mit Multiarch kompatibel ist und parallel zum nativen Paket installiert werden kann (z.B Bibliotheken),
  • foreign heißt, dass das Paket nicht parallel installiert werden kann (z.B Systemdienste oder auch ausführbare Programme)
  • und allowed meint, dass ein architekturfremdes Paket davon abhängen darf.

Aber die ganze Sache hat auch Nachteile. Zum einen ist der Multiarch-Support noch nicht standardisiert und eine reine Debian/Ubuntu-Geschichte. Ob andere Distributionen mitmachen, die mitunter schon eigene Lösungen haben, bleibt abzuwarten. Zum anderen fördert die Multiarch-Unterstützung das Verharren auf alten Architekturen, wie man das unter Windows beobachten kann. Viele Software gibt es nur als 32-Bit, weil das ja auch auf 64-Bit läuft. Damit muss man letztendlich noch ein halbes 32-Bit-System mitinstallieren und im Arbeitspeicher halten, mit reinen 64-Bit-Anwendungen entfällt dieser Schritt komplett.

Außerdem ist das Thema langsam gegessen. Denn die Nicht-Verfügbarkeit von 32-Bit-Software unter 64-Bit hat dazu beigetragen, dass fast jedes Linux-Programm auch als 64-Bit verfügbar ist. Bei Open-Source-Programmen sowieso; den Firefox zum Beispiel gab es lange für 64-Bit-Linux, schon bevor Mozilla vor kurzem angefangen hat, selbst 64-Bit-Binaries bereitzustellen. Proprietäre Anwendungen gibt es auch nur noch wenige, die nicht für 64-Bit verfügbar sind, wie etwa Flash. Aber auch hier hat Adobe vor, mit Version 11 64-Bit Support einzuführen.

Den Vorteil von Multiarch sehe ich in Cross-Compilation in Kombination mit QEMU. So wird etwa das Erstellen von Binaries für ARM unter einem leistungsfähigen x86_64 -System transparent und out-of-the-box möglich sein, anschließend ließe sich das Kompilat mittels QEMU gleich ausprobieren.

Und was ändert sich für den normalen Nutzer? Nur, dass er keine Fehlermeldung mehr kriegt, wenn er versucht, ein 32-Bit-Programm unter seinem 64-Bit-System zu installieren – es funktioniert einfach.

Bis es soweit ist, muss noch ein weiter Weg gegangen werden – schließlich bedeutet Multiarch eine radikale Umstellung des Dateisystems und die Konvertierung von vielen Paketen, sowie möglicherweise Kompatibilitätsprobleme mit älteren Distributionsversionen und anderen Distributionen.

About these ads

11 thoughts on “Endlich da, aber eigentlich zu spät: Multiarch-Support

  1. Was ist denn mit getlibs? Wenn ich eine 32-Bit-Anwendung habe, lasse ich getlibs drüberlaufen und alles ist gut auf meinem 64-Bit-System.

    • Vielleicht habe ich den Text nicht richtig gelesen, aber ich sehe da keinen wirklichen Vorteil bzw Unterschied zu vorher, abgesehen von der wegfallenden Fehlermeldung …. man hat jetzt mehrere Verzeichnisse für die libs (/lib/32 /lib/64) und später genauso, eigentlich sogar noch mehr … und die Pakete? die werden offenbar nur etwas anders aufgeteilt hmm :-?

      • @Aleks: Der Unterschied ist die reduzierte Arbeit für die Maintainer. Bisher musste, um 32-Bit Bibliotheken auf 64-Bit-Systemen bereitzustellen, das Monsterpaket ia32-libs, das die bekanntesten Bibliotheken enthält, sowie einzelne lib32-Pakete extra gepflegt werden, und für jede 32-Bit Anwendung musste ebenfalls ein extra Paket erstellt werden. Und das alles erfordert natürlich Wartung und Tests.

        Mit Multiarch fällt das alles weg, alles läuft automatisch, man kann 32-Bit-Pakete einfach unter 64-Bit verwenden ohne eine Extrawurst. Außerdem funktioniert Multiarch auch mit non-x86-Architekturen, wie etwa PPC32 unter PPC64, oder verschiedene MIPS-Varianten, oder ARM unter x86 mit Emulation.

    • @Dee: Getlibs ist auch nur ein Hack – es holt sich die Bibliotheken zwar aus den Paketquellen, der Paketmanager bekommt von den zusätzlich installierten 32-Bit-Bibliotheken aber nichts mit, man muss sie also selber wieder deinstallieren (Quelle: persönliche Erfahrung, leider scheint es keine ausführliche Dokumentation über die Arbeitsweise von getlibs zu geben). Und richtig benutzerfreundlich ist es auch nicht.

  2. Dann kann ich meine Chroot ja endlich einmotten ;)

    Fehlt mir aber noch die Möglichkeit, 32bit-Quellen in einem 64bit-System zu verwenden (oder ist das auch geplant?)

    btw, schöner Artikel!

    • Genau darum geht es bei Multiarch. Du kannst aus jeder Quelle neben deiner nativen Architektur auch Pakete aus anderen Architekturen installieren. Man kann auch bei jeder Quelle einzeln angeben, welche Architekturen man nutzen will:

      deb [arch=i386,amd64] http://foo.bar/ test section
  3. Zitat “Aber die ganze Sache hat auch Nachteile. Zum einen ist der Multiarch-Support noch nicht standardisiert und eine reine Debian/Ubuntu-Geschichte. Ob andere Distributionen mitmachen, die mitunter schon eigene Lösungen haben, bleibt abzuwarten” Zitat ende.

    Wenn ich mich nicht täusche dann unterstützt Fedora auch schon seit ewig Zeiten mehrere Architekturen und macht das genauso mit dem :.
    Oder täusche ich mich da etwa?

    • Ja, aber Fedora nutzt nicht dieselben Dateipfade wie Debian und Ubuntu bei Multiarch, Dinge wie /usr/lib/i386-linux-gnu gibt es bei Fedora meines Wissens nicht (auch nicht im FHS). Das sind also alles distributionseigene Lösungen, die Paketmanager entfernen sich noch weiter voneinander. Besser wäre es, sich gemeinsam auf eine Lösung zu einigen, aber man hat schon früher versucht, die Paketmanager der Distributionen zusammenzuführen und es hat nicht funktioniert.

  4. Na das wurde ja auch wirklich Zeit. Mich ärgert es immer wenn M$ wirklich Sachen implementiert/besser gelöst hat als Debian ;)

  5. > Einige Architekturen, wie x86_64, sind in der Lage, über einen _Kompatibilitätsmodus_ alte x86-Programme auszuführen

  6. Upgrade vom Ubuntu Server 11.10 auf 12.04 LTS | gurunest.com

Die Kommentarfunktion ist geschlossen.