© photocase.com

Die viel gerühmte Vielfalt bei freier Software bringt nicht nur Vorteile, sondern auch Probleme. Allein die Website Distrowatch zählt über 350 Distributionen – und die kochen in vielen Fragen ihr eigenes Süppchen. Die Linux Standard Base sorgt dafür, dass konforme Anwendungen überall laufen.

Je mehr Distributionen auf den Markt kommen, desto schwieriger wird es für einen Entwickler, die Kompatibilität seiner Software sicherzustellen. Für Anwender bedeutet dies in der Regel selbst Hand anlegen und das Programm aus den Quellen erstellen – oder ganz darauf zu verzichten. Gerade Einsteiger in die Linux-Welt tun sich beim Basteln jedoch meist schwer, sind sie es doch von Windows gewohnt, die Dateien auf die Platte kopieren zu lassen und einfach zu starten. Zudem bleibt bei dieser Methode die erstellte Anwendung an die entsprechende Distribution gekettet.

Offene Standards

Diese Probleme hat auch die Free Standards Group (kurz FSG, [1]) erkannt, der neben den großen Distributionsherstellern wie Red Hat, Novell (Suse) oder Mandriva auch viele weitere bekannte Unternehmen aus der Linux-Welt angehören, darunter IBM, Intel, HP, AMD, Dell und Sun. Die FSG hat es sich als unabhängige und gemeinnützige Organisation zur Aufgabe gemacht, die Nutzung freier Software voranzutreiben und dafür Standards entwickeln. Daher verwundert es nicht, dass sich ihre Arbeitsweise stark an der von Open-Source-Projekten orientiert. So ist der Standardisierungsprozess für jedermann offen und alle wichtigen Dokumente unterliegen der GNU Free Documentation License.

Großes Gremium

Mit der Linux Standard Base Workgroup [2] übernahm schließlich eine Untergruppe der FSG die schwere Aufgabe, die gröbsten Inkompatibilitäten zwischen den Distributionen mit einem neuen Standard aus der Welt zu schaffen. Er sollte einerseits die problemlose Installation kompilierter Software gewährleisten, andererseits den Distributoren und Anwendungsentwicklern möglichst wenig Vorschriften machen.

Um diesen Spagat zu bewältigen, griff die Gruppe auf bereits bestehende Standards zurück. Primär waren dies Posix (Portable Operating System Interface) und die Single Unix Specification (SUS, [3]) ergänzt um den Filesystem Hierarchy Standard (FHS) und OpenI18N (Open Internationalization). Die letzten beiden Standards werden ebenfalls von der FSG betreut.

Binärkompatibilität

Das Ergebnis mit dem Namen Linux Standard Base (LSB), erblickte 2001 das Licht der Welt und erfuhr im Lauf der Jahre mehrere Überarbeitungen. Seit Juli 2005 ist Version 3 aktuell, in der freien Wildbahn trifft man aber noch überwiegend auf den Vorgänger. Die LSB besteht aus mehreren Dokumenten, die genau vorschreiben, wie eine binäre Anwendung und das umgebende Linux-System auszusehen haben.

Im Gegensatz zu anderen Standards macht die LSB nur wenige Vorschriften auf Quellcode-Ebene. Sie definiert ein so genanntes Application Binary Interface (ABI), das festlegt, wie die binären Schnittstellen (Binary Inferfaces) aussehen müssen, damit eine Anwendung auf dem System läuft. Hierzu zählt beispielsweise die Vorschrift, dass kompilierte Programme als Linker-Schnittstelle das ELF-Format verwenden. Der Anbieter einer so genannten LSB-Laufzeitumgebung (Runtime Environment) – in der Regel wohl eine Linux-Distribution – kann somit die Art und Weise der Implementierung selbst wählen.

Damit die Hersteller von Anwendungen und Laufzeitumgebungen nicht in Versuchung geraten, die Spezifikationen aufzuweichen, führte die FSG einen Zertifizierungsprozess ein. Nur wer diesen erfolgreich durchläuft, darf sein Produkt mit dem werbeträchtigen LSB-Logo schmücken (Abbildung 1).

Abbildung 1: Software, die die Anforderungen der Linux Standard Base erfüllt und sich den entsprechenden Tests unterzieht, darf sich mit dem LSB-Logo schmücken.

Ein LSB-zertifiziertes System garantiert, dass eine LSB-konforme Anwendung ohne weitere Anpassungen auf ihm läuft. Da eine solche Anwendung nur noch einmal kompiliert werden muss, reduzieren sich Arbeitsaufwand und Kosten. Im Idealfall genügt sogar die Bereitstellung eines einzelnen Binärpakets. Mittlerweile sind alle großen kommerziellen Distributionen wie Suse, Red Hat oder Mandriva zertifiziert.

Teile und herrsche

Nachdem die LSB in der ersten Version noch aus einem großen Dokument bestand, ist das Gremium später dazu übergegangen, die LSB in verschiedene Teile, die so genannten Module aufzuspalten. Neben den allgemein gültigen Anforderungen in der Generic LSB (GLSB) gibt es noch die architekturabhängigen Spezifikationen (ArchLSB). Auf diese Weise kann der Standard die unterschiedlichen Hardwareplattformen leichter berücksichtigen.

Derzeit unterstützt die LSB die Architekturen X86 (neben IA32 auch X86_64), Itanium (IA64), PowerPC (32 und 64 Bit), S390 und S390X. Ein Linux-System, das die LSB einhält, erfüllt immer alle Spezifikationen aus dem GLSB-Teil und dem entsprechenden ArchLSB-Modul. Seit LSB 2.0 ist auch der generische Teil noch einmal in Module unterteilt (siehe Kasten “Gruppierung”).

Damit der Austausch von binären Programmen reibungslos klappt, müssen Anwendungshersteller und Distributoren sicherstellen, dass ihre Produkte den in der LSB genannten Bedingungen genügen. Um diesen Prozess zu vereinfachen, stellt die Free Standards Group auf ihren Seiten kostenlose Softwarewerkzeuge bereit.

Wer jetzt hastig die Download-Maschine in Gang setzen will, sollte bedenken, dass die LSB derzeit nur die binären Ergebnisse der Sprachen C und C++ unterstützt. Java ist beispielsweise nicht Linux-spezifisch und wird daher auch nicht erfasst. Gleiches gilt für andere interpretierte Sprachen wie Tcl, Perl oder Python. Bei ihnen kommt hinzu, dass es meist keinen formalen Standard gibt, auf den sich die LSB beziehen könnte.

Tests und Werkzeuge

Die Entwicklung einer LSB-konformen Anwendung besteht aus mehreren Schritten. Zunächst sollte der Entwickler sicherstellen, dass die Linux-Distribution selbst LSB-konform ist. Damit vermeidet er eine Reihe von ansonsten notwendigen Tests. Manche Distributoren packen die LSB-spezifischen Werkzeuge und Bibliotheken in ein eigenes Paket. Unter Suse trägt es beispielsweise den Namen »LSB«. Zu den darin enthaltenen Kommandos zählt unter anderem »lsb_release«, das die Versionsnummer der zugrunde liegenden LSB mit den verwendeten Modulen wie »core« oder »graphics« ausgibt:

$ lsb_release
LSB Version:
 core-2.0-noarch:core-2.0-ia32:graphics-2.0-ia32:graphics-2.0-noarch

Diese Kommandos setzen die nachfolgend beschriebenen Testprogramme voraus. Fehlen sie, erscheint bereits beim Einspielen der RPM-Pakete eine Fehlermeldung.

Beim Schreiben des Quellcode beugt ein kurzer Blick in die LSB-Spezifikationen bösen Überraschungen vor. So sollten Programmierer am besten das Posix-API benutzen und nur auf die wenigen erlaubten Bibliotheken wie Libc, Libncurses oder Libx11 zurückgreifen. Alle selbst erstellten oder nicht in der LSB-Liste enthaltenen Bibliotheken sind entweder statisch zu linken oder der Anwendung beizulegen. Im letzteren Fall müssen die Bibliotheken selbstverständlich ebenfalls die Bedingungen der Linux Standard Base erfüllen.

Standardisierte Entwicklungsumgebung

Um die Einhaltung dieser Vorgaben bereits zur Compile-Zeit sicherzustellen, bietet die FSG eine hilfreiche Werkzeugsammlung unter der Bezeichnung LSB Development Environment an. Sie lässt die Wahl zwischen zwei Vorgehensweisen, die sich in den Paketen »lsb-build-cc« und »lsb-build-chroot« widerspiegeln.

Die darin enthaltenen Programme stellen auf unterschiedliche Weise sicher, dass entwickelte Anwendungen automatisch der LSB gehorchen. Dabei greifen sie auf die Bibliotheken und Headerdateien aus dem Paket »lsb-build-base« zurück. Letzteres ist demnach in beiden Fällen zuerst zu installieren:

rpm -i lsb-build-base

Das zweite Paket »lsb-build-chroot« konstruiert mit Hilfe des Chroot-Kommandos eine minimale Entwicklungsumgebung. Sie blendet einfach alles aus, was nicht der LSB entspricht. Der Compiler hat somit keine andere Wahl, als LSB-konformen Code zu erzeugen.

Um ein Programm zu erstellen, editiert der Entwickler zunächst die Datei »/etc/lsbdev-chroot/lsbdev-chroot.conf« und fügt das eigene Homeverzeichnis zu »BUILDUSERS« hinzu. Der zu Hilfe gerufene SSH-Daemon bindet es später automatisch in die Umgebung ein. Dann startet er das zuständige Skript mit der Eingabe »/etc/init.d/lsbdev-chroot start« und loggt sich in die damit erzeugte Umgebung ein:

slogin -p 5436 localhost

Das Startskript stellt den SSH-Daemon auf den Port 5436 ein. Der gewohnte GCC-Aufruf übersetzt dann das Programm »hello.c«:

$ gcc -o hello hello.c

Einen anderen Weg geht »lsb-build-cc«. Dieses Paket enthält mit »lsbcc« für C, beziehungsweise mit »lsbc++« für C++ einen Wrapper für den jeweiligen GCC-Compiler. Dabei ruft »lsbcc« den Compiler einfach nur mit passenden Parametern auf und stellt gleichzeitig sicher, dass dabei die korrekten ABIs verwendet werden.

Versionen prüfen

So ist gewährleistet, dass die Versionsnummern der Bibliotheken mit den in der LSB vorgeschriebenen übereinstimmen. Es genügt also, in seinen C-Projekten den Compiler gegen »lsbcc« beziehungsweise in C++-Projekten gegen »lsbc++« auszutauschen. Oft reicht bereits:

CC=lsbcc ./configure

Wie »lsbcc« auftretende Probleme abfängt, zeigt sich beim Versuch, das Hello-World-Beispiel aus Listing 1 mit dem Funktionsaufruf »__getpid()« zu kompilieren (Abbildung 2). In diesem offenbar nicht LSB-konformen Hello-World-Programm bemängelt »lsbcc« zu Recht die Funktion »__getpid()«, die für LSB nicht Teil der Standard-C-Bibliothek ist.

01 #include <stdio.h>
02 #include <unistd.h>
03 
04 int main()
05 {
06     printf("Hello from PID: %dn", __getpid());
07     return 0;
08 }

Abbildung 2: Der LSB-Wrapper für den GCC verweigert die Kompilierung des Programms, das eine Funktion verwendet, die zwar vorhanden, aber nicht Teil des Standards ist.

Bibliothekarisch

Die Methode über »lsb-build-cc« bringt aber ein Problem beim Erzeugen dynamischer Bibliotheken mit sich. Würden sie per »ld« erstellt, könnte dies Ergebnisse zur Folge haben, die nicht LSB-konform sind. Daher sollte man bei ihrer Erstellung immer den Weg über »lsbcc« gehen. Die Zeile

ld -r -shared -o libhello.so obj1.o obj2.o

erhält dann beispielsweise die folgende Form:

lsbcc -shared -o libhello.so obj1.o obj2.o

Beim Einsatz von »lsb-build-chroot« ist dieser Kunstgriff nicht notwendig. Dort regelt die Umgebung alles.

Test, Test, 1 ,2, 3

Das Programm »lsbappchk« testet schließlich noch das fertige Programm auf LSB-Konformität. Sein Einsatz ist besonders dann sinnvoll, wenn der Entwickler das Programm nicht über eine der beschriebenen LSB-Umgebungen erstellt hat. Kompiliert er beispielsweise das Programm aus Listing 1 einfach mit »gcc«, erhält er zwar ein funktionierendes Ergebnis:

$ gcc -o hello hello.c
$ ./hello
Hello from PID: 8576

Den LSB-Standard erfüllt das Ergebnis aber nicht: »lsbappchk« stellt korrekterweise fest, dass das Binary die nicht LSB-konforme Funktion »__getid()« verwendet:

linux:~ # /opt/lsb/bin/lsbappchk hello
Checking binary hello
...
Section .note.SuSE: Not recognized by name.Checking as type SHT_NOTE
Symbol __getpid used, but not part of LSB_Core

Dynamische Bibliotheken lassen sich übrigens auf die gleiche Weise testen, wobei hinter »lsbappchk« zusätzlich der Parameter »-L« folgt.

In der obigen Fehlermeldung ist die Zeile »section .note.SuSE is not in the LSB« übrigens eine Suse-typische Besonderheit: Das ELF-Format besitzt so genannte Sektionen, von denen in diesem Fall eine ».note.SuSE« heißt, aber nicht von der LSB definiert ist. Novell schreibt dazu nur lapidar, dass diese Sektion lediglich einen String enthalte und somit alles gut sei. Zwar steht dieser zusätzliche Eintrag der Kompatibilität nicht im Wege, hinterlässt aber im Hinblick auf eine Standardisierung doch einen unangenehmen Beigeschmack.

Ist das Programm fertig, geht es ans Einpacken, wofür die LSB das RPM-Format vorsieht. Die FSG entschied sich dafür, weil alle Distributionen es verarbeiten können. Da die LSB bis auf wenige Ausnahmen keine Vorgaben für die mitgelieferten Programme macht, ist in einer Distribution »rpm« nicht unbedingt erforderlich – der Benutzer muss lediglich das Archiv entpacken können.

Für ein RPM-Archiv gelten allerdings einige Einschränkungen. Beispielsweise gehören Startskripte in das Verzeichnis »/etc/init.d« und müssen mit bestimmten, festgelegten Argumenten zurechtkommen. Darüber hinaus ist es notwendig, dass der Name der RPM-Datei dem vorgeschriebenen Schema »lsb-meineDomain.org-Paket« folgt.

Ein LSB-konformes Paket beginnt stets mit »lsb-«. Sofern nur ein Bezeichner folgt, ist er bei der Lanana (Linux Assigned Names and Numbers Authority [4]) zu registrieren. Folgt mehr als eine Zeichenkette, muss als Erstes entweder ein registrierter Herstellername erscheinen oder aber der Domainname in Kleinbuchstaben. Das Programm »lsbpkgchk« (LSB package verification tool) aus dem gleichnamigen Paket überprüft alle genannten Bedingungen.

Bestanden

Hat es das eigene Programm bis hierhin geschafft, kann der Entwickler bei der FSG eine LSB-Zertifizierung beantragen. Dazu sind eine Registrierung auf der entsprechenden Internetseite und die Durchführung der Tests durch die LSB Certification Authority notwendig. Dieses Verfahren belastet jedoch die Geldbörse, als Gegenleistung darf das Programm das Logo der LSB verwenden. Nach einer bestimmten Zeit muss es erneut dem Zertifizierungsprozess unterzogen werden. Andernfalls verfällt die Zertifizierung. Dies gilt auch für LSB-zertifizierte Distributionen.

Neben den vorgestellten Testwerkzeugen bietet die FSG eine LSB Sample Implementation (LSB-si) an. Sie enthält eine minimale LSB-konforme Laufzeitumgebung. Man kann sie sich vorstellen wie eine kleine Linux-Distribution. Dennoch weisen die LSB-Seiten ausdrücklich darauf hin, dass die LSB-si eine Beispiel- und keine Referenzimplementierung ist. Mit ihr möchte die FSG zum einen die Spezifikation demonstrieren und zum anderen die Testwerkzeuge validieren. Darüber hinaus erlaubt sie es, in ihr eigene Programme zu testen, um so noch verbliebene Distributionsabhängigkeiten auszuschließen.

Auf den Internetseiten der FSG gibt es die LSB-si in drei Geschmacksrichtungen: Chroot-LSB-si, die eine Chroot-Umgebung nutzt, eine Usermode-Linux-Variante und sogar eine bootfähige Knoppix-LSB-si. Die jeweils zugehörigen Paketnamen sind an der Zeichenkette »lsbsi-« zu erkennen. Beim Download ist zu beachten, dass nicht alle Archive einen Kernel enthalten, da er je nach gewählter Methode nicht immer notwendig ist. Wer dennoch einen braucht, bedient sich beim Paket »lsbsi-boot«. Für alle Varianten ist mindestens noch das Paket »lsbsi-core« erforderlich. Zusätze gibt es in Form der Pakete »lsbsi-graphics« mit einer grafischen Umgebung und »lsbsi-test«, das die Beispielimplementierung zu einer Testumgebung aufrüstet.

vsx0$ ./run_tests

/opt/lsb/bin/lsblibchk [-M Modulname]

Aufgeladen

Ergänzend zur LSB-si steht die so genannte Application Battery bereit. Unter diesem Punkt ist eine Reihe von mehr oder wenige populären Programmen zu finden, die LSB zertifiziert sind – mit dem Apache Webserver oder XPDF auch Beispiele für größere LSB-konforme Anwendungen. Zusätzlich helfen sie bei der Verifikation einer LSB-konformen Laufzeitumgebung. Auf einem produktiven System haben sie jedoch nichts zu suchen: So wurden beispielsweise einige Funktionen deaktiviert, um die LSB-Konformität zu erreichen.

Fazit

Dass die LSB durchaus auch Kritiker hat, zeigt ein Blog-Beitrag des Red-Hat-Mitarbeiters Ulrich Drepper [5]. Er kritisiert vor allem die Testprogramme, die aufgrund ihrer Fehlerhaftigkeit Probleme melden, die gar nicht vorhanden wären (“… but it’s safe to say 90+% of the reported bugs are actually problems in the test suite”), was sogleich eine Diskussion im Internet auslöste.

Auch wenn die LSB derzeit kontrovers betrachtet wird, hilft sie insbesondere den unabhängigen Softwareherstellern (ISV, Independent Software Vendors) dabei, den Portierungs- und Testaufwand zu verringern. Darüber hinaus sorgen viele Teilstandards, etwa der FHS, bereits seit vielen Jahren für Ordnung im Distributionsgewirr. Dass LSB 2 seit einigen Wochen auch ein ISO-Standard ist, dürfte die allgemeine Akzeptanz noch weiter fördern. Auch Version 3.1 möchte die LSB demnächst zur Standardisierung einreichen. (ofr)