Karl Sinn wrote:
Na ja, aber Microsoft, kriegt das doch auch hin, und wenn ich mich recht erinnere, dann machen die das dadurch, dass Bill Gates bei den Hardwareherstellern eingreift, und eine gewisse Standardisierung vorschreibt. Diese Standardisierung müsste doch unter Linux auch für vereinheitlichung sorgen?
Das tut sie sogar. Jedenfalls, wenn sie funktioniert und die Standards offen sind. ACPI zum Beispiel ist ein klassicher Fall, in dem ein Standard existiert und nicht funktioniert. Mein Dell Notebokk ist inzwischen bei BIOS ROM A14, und ein Disassembly vom ACPI ROM zeigt nachweislich immer noch Fehler in den Descriptortabellen. Dell hat es in vierzehn Revisionen nicht geschafft, die sauber aufzuräumen. Windows bringt hier eine eigene Tabelle mit, d.h. Windows ignoriert hier das kaputte ROM und überschreibt dies mit eigenen Infos. Linux hält sich an den Standard und verläßt sich darauf, daß der Hersteller das auch tut -> Bumm beim Zuklappen des Notebookdeckels.
Wieso ist so eine scheinbar "wichtige" Bibliothek nicht abwärtskompatibel bzw. warum binden Entwickler, die das Problem doch sicher kennen, in so einem Fall Ihre Version der Bibliothek nicht direkt mit ins Programm ein?
Die glibc ist ein spezialgelagerter Sonderfall. Deren Entwickler gehören möglicherweise einige Tage an den Eiern aufgehängt. Alternativ kann man sich ein Verfahren überlegen, mit dem sich ca. 4 glibc-Versionen parallel installieren und verwenden lassen. Das ist das, was unter Windows gemacht wird: Dort prüfen viele Programme, ob die vom Programm benötigten .so im System sind und wenn nein, klatschen Sie einfach eine Kopie davon ins SYSTEM32-Verzeichnis. So hat eine typische Windows-Installation dann oft 3-10 Versionen der Visual Basic Bibliotheken oder der MS 3D Controls im SYSTEM32-Verzeichnis... Kristian