Ist mir was entgangen, ich nutze jetzt seit ca 3 Jahren Gentoo und wüsste nix davon, dass Gentoo LSB zertifiziert ist und schon gleich gar nicht für die 3.0
Weiß jmd., ob der FHS angepasst wurde? D. h., wurde festgelegt, wo z. B. Gnome und KDE installiert werden müssen?
> "Anwendungen, die LSB-konform sind, sollen ohne Neucompilierung auf allen LSB-konformen Distributionen laufen."
So weit mir bekannt ist, läuft eine Gnome/KDE-Anwendung die unter SUSE erstellt nicht ohne Probleme unter Redhat, da die Speicherorte für Gnome/KDE unterschiedlich sind.
Ansonsten hatte ich daneben oft andere Probleme, dass abhängige Bibliotheken anders heißen etc., so dass es im Moment aus meiner Sicht nicht problemlos möglich ist Anwendungen die unter einer Distribution erstellt wurden, unter einer anderen Distribution aus zu führen.
Bei GNOME ist es egal, wohin es installiert wurde. Man kann problemlos GNOME-Anwendungen in /usr/local installieren. Menüeinträge gehören nach freedesktop.org-Spezifikation nach /usr/share/applications, unabhängig davon, wohin GNOME installiert wurde. /usr/share/applications ist schließlich desktopübergreifend.
KDE-Anwendungen kann man auch installieren, wohin man will, nur muss man vor dem Start die Variable KDEDIR anpassen. Darum kann sich aber ein Startskript kümmern. Das Mozilla-Startskript setzt schließlich auch LD_LIBRARY_PATH etc. neu, damit die Mozilla-Libs von ld gefunden werden.
> KDE-Anwendungen kann man auch installieren, wohin man will, nur muss man > vor dem Start die Variable KDEDIR anpassen.
Fast richtig, KDEDIRS heißt die Variable. KDEDIR war mal und sollte - theoretisch - nicht mehr benötigt werden, aber es kann nie schaden sie doch noch zu setzen, auf den Prefix der kdelibs/kdebase-Installation. Für zusätzliche Anwendungen reicht aber ein Eintrag in KDEDIRS (und PATH)
Von Kevin Krammer am Di, 20. September 2005 um 01:18 #
Obwohl man da eventuell noch auspassen muß. /usr/share/applications ist das Standardverzeichnis, wenn man eine Applikationen in den Prefix /usr/local installiert könnte es sinnvoller sein, Menüeinträge nach /usr/local/share/applications zu installieren und XDG_DATA_DIRS entsprechend zu erweitern.
Von thomas001 am Di, 20. September 2005 um 01:29 #
dann sind das keine LSB libraries,deren namen sind genormt... naja und kde/gnome/foo wuerde ich sagen gehoert nach /usr. /opt/kde oder wo das andere hintun is zwar nich direkt falsch,aber dafuer sehe ich eigentlich keinen grund...
Ich habe mal vor längerer Zeit einen link von /opt/kde nach /usr gesetzt und konnte dann auch eine Suse rpm unter Mandrake installieren. Sollte eigentlich immer noch funktionieren. Probleme hatte ich aber bei Serveranwendungen mit den unterschiedlichen Startscripten und Config-Dateien (rcconfig ...).
> Läuft da nicht irgendwas falsch, wenn der Standard > der Software angepasst wird (anstatt umgekehrt)?
Könnte man meinen. Vor allem frage ich mich aber, woher die ständige C++-Problematik des GCC überhaupt kommt. Es ist ja nicht das erste Mal. Ist ein Ende abzusehen?
Im Moment führt ja kaum ein Weg daran vorbei, sämtlichen C++-Code bis auf die libstdc++ statisch ins Binary zu linken und den Benutzern alter Distributionen ein Exemplar der libstdc++.so.6 mitzuliefern, wenn man ein Binary erstellen will, das auf allen Distributionen läuft.
Bitte nicht gleich mit "aber man kann doch neu kompilieren, wenn man den Quellcode hat" kommen. Ja, kann man, will aber nicht jeder und außerdem geht es bei der LSB genau darum, es nicht mehr zu müssen, selbst wenn man könnte. KDE-Anwendungen sind beispielsweise praktisch unmöglich für alte und neue Distributionen zu packen. Das kann doch keiner wollen.
Übrigens: Der beschriebene Sachverhalt ist einer der Gründe, weshalb das auf www.openoffice.org angebotene Linux-Binary von OpenOffice.org um ca. 20% größer ist als das Windows-Binary.
nein, solange die distributionen beide libstdc++ libs mitliefern ist das kein problem. Ein KDE programm für SUSE 9.3 (gcc 3.3 mit alter ABI) läuft ohne probleme auf der 10.0 mit gcc 4 (neue ABI). Die programme können gleichzeitig gegen beide libs linken, daher macht es nichts dass qt/kde libs gegen die neue linken und das Programm gegen die alte.
> nein, solange die distributionen beide libstdc++ libs > mitliefern ist das kein problem.
Stimmt nicht.
> Ein KDE programm für SUSE 9.3 (gcc 3.3 mit alter ABI) > läuft ohne probleme auf der 10.0 mit gcc 4 (neue ABI).
Das ist nicht wahr. Jede KDE-Anwendung benötigt die kdelibs in derselben ABI-Version wie die Anwendung selbst. Eine KDE-Anwendung der neuen ABI kann die kdelibs der alten ABI nicht nutzen und eine KDE-Anwendung der alten ABI kann die kdelibs der neuen ABI nicht nutzen.
Es ist unmöglich, dynamisch gelinkte C++-Software unterschiedlicher ABI ein und dasselbe Exemplar einer C++-Bibliothek nutzen zu lassen. Deswegen reicht es eben gerade nicht, die libstdc++ doppelt auszuliefern, sondern man müsste alle C++-Bibliotheken doppelt ausliefern. Dies geht allerdings auch nicht, weil sich die SO-Names der C++-Bibliotheken mit Ausnahme der libstdc++ nicht ändern, da sich nur ihre ABI, nicht aber ihre API ändert.
Fazit: Nein, so leid es mir tut, es ist nicht möglich, was Du vorschlägst. Auch die Parallelinstallation mehrerer gleichnamiger Bibliotheken in verschiedene Verzeichnisse ist kein praktikabler Weg. Falls Du es mir nicht glaubst: Kein Problem. Verfolg einfach die Entwicklung bei Debian oder irgendeiner anderen Distribution, bei Debian sieht man es allerdings besonders deutlich, oder lies hier:
> Die programme können gleichzeitig gegen beide libs > linken, daher macht es nichts dass qt/kde libs gegen > die neue linken und das Programm gegen die alte.
Erstens stimmt das nicht und zweitens wäre es sowieso sinnlos, weil die ABI-Frage keine Frage des dynamischen Linkens gegen unterschiedliche Versionen der libstdc++ ist. Die einzige Lösung besteht darin, sämtlichen C++-Code statisch zu linken, nur die libstdc++ nicht. Die libstdc++ auch noch statisch zu linken, ist sogar kontraproduktiv, weil man sich dadurch eine Abhängigkeit von einer ganz bestimmten glibc-Version einfangen würde, die man sonst nicht hätte.
Das erste "Stimmt nicht" muss ich der Korrektheit halber doch einschränken: Natürlich stimmt es für Programme, die selbst in C++ geschrieben sind und keine C++-Bibliotheken außer der libstdc++ nutzen, insofern ist die Aussage "Stimmt nicht" falsch, es müsste "Stimmt im Allgemeinen nicht" heißen.
Die wichtigsten und interessantesten C++-Anwendungen (KDE, Qt) tun dies jedoch, deswegen stimmt es bei denen tatsächlich nicht. Nochmal zur Verdeutlichung: Das Problem ist NICHT die libstdc++, die ja bekanntlich problemlos parallel installierbar ist, sondern die ABI. Der dynamische Linker kann zur Laufzeit keinen Code unterschiedlicher ABI in ein und denselben Prozess laden.
Deswegen dürfen bzw. können C++-Programme nur Code von ein und derselben ABI enthalten. Es gibt drei Möglichkeiten, damit dies der Fall ist:
- das Programm ist selbst in C++ geschrieben, nutzt aber keine C++-Bibliotheken (nicht der Fall bei KDE- und Qt-Anwendungen) - das Programm nutzt C++-Bibliotheken und ist statisch gegen diese gelinkt (relativ gut machbar bei Qt, kaum machbar bei KDE) - das Programm nutzt C++-Bibliotheken und bringt diese selbst mit (relativ gut machbar bei Qt, praktisch ausgeschlossen bei KDE)
Nur als Hinweis: Qt und KDE sind bzw. enthalten die bekanntesten, wichtigsten und meistbenutzten C++-Bibliotheken, sind aber keineswegs die einzigen Beispiele. Wer Zeit hat, kann eine wirklich lange Liste aufstellen. wxWidgets würde zum Beispiel auch auf dieser Liste stehen. Das ändert seine API (API, nicht ABI) und seine SO-Names allerdings so oft, dass man es sowieso statisch linken sollte, wenn Portabilität wichtig ist.
Von Anonymous am Di, 20. September 2005 um 14:07 #
> Läuft da nicht irgendwas falsch, wenn der Standard der Software angepasst wird (anstatt umgekehrt)? Im prinzip ja, aber: wenn die alte ABI (Compiler UND Spec) Fehler enthält, dann sollten die korrigiert werden. Und da es öfters neue Compilerversionen gibt als neue Specs, werden die Fehler zuerst im Compiler behoben und erst später in den Specs. Und wenn man Glück hat, reicht es bei der Spec, einfach nur die neue ABI des Compilers zu übernehmen.
Was tatsächlich bei der ABI-Änderung ablief, kann ich nicht zuverlässig sagen. Lies die Specs und die gcc-Changelogs. Aber ich glaube mich erinnern zu können daß es da Fehler gab, die behoben werden mussten.
> Im prinzip ja, aber: wenn die alte ABI (Compiler UND Spec) > Fehler enthält, dann sollten die korrigiert werden.
Ich habe auch keine Detailkenntnis über die Ursachen der ständig wiederholten inkompatiblen ABI-Änderungen, aber eines ist und bleibt trotzdem pervers: Und zwar die Tatsache, dass es möglich ist, auf einem Linux-System mit nagelneuen Bibliotheken uralte Windows- und DOS-Binaries zusammen mit Bibliotheken egal welchen Alters auszuführen, nicht aber mäßig "alte" oder auch "zu neue" Linux-Binaries, und zwar unabhängig von der benutzten Programmiersprache.
> Aber ich glaube mich erinnern zu können daß es da Fehler > gab, die behoben werden mussten.
Fehlerbehebungen sind super, trotzdem stellt sich in jedem Einzelfall immer wieder die Frage, wie man es denn nun konkret anstellt. Ein bekannter Softwarehersteller, der wegen der unüberbietbaren Fehlerhaftigkeit seiner Produkte angeblich seit Jahren kurz vor dem Untergang steht, ist bisher ohne inkompatible ABI-Änderungen ausgekommen, die das Neukompilieren sämtlicher Software in einer bestimmen Programmiersprache erfordern.
Nein, die Lügen gewisser Interessengruppen über angeblich noch viel häufigere ABI-Änderungen sind nicht wahr und auch die wahrscheinlich bald kommende Behauptung, auf dieser Plattform gebe es keine Bibliotheksteilung, ist ebenfalls unrichtig. Komponenten und Bibliotheken werden in großem Umfang zwischen dem Basissystem und den Anwendungen gemeinsam benutzt und bleiben über Jahre hinweg kompatibel.
Über die angebliche Notwendigkeit des ABI-Wechsels beim GCC kann ich mir, wie gesagt, kein Werturteil erlauben, trotzdem bleibt festzuhalten, dass Konkurrenzprodukte, da sind wir uns ganz bestimmt alle einig, auch schwerwiegende Fehler aufweisen, die aber ohne inkompatiblen ABI-Wechsel gelöst werden konnten. Das ist vielleicht etwas schwieriger und kostet möglicherweise auch etwas mehr Geld in der Entwicklung, macht dafür aber einen wesentlich solideren und besseren Eindruck.
| und zwar unabhängig von der Programmiersprache Das stimmt nicht. Nur C++ macht solche Probleme.
Die ABI-Wechsel beim g++ haben auch damit zu tun, dass man endlich kompatibel zu allen anderen C++-Compilern sein will. Es soll möglich sein, mit dem Intel C++-Compiler kompilierte Binaries gegen g++-kompilierte Libs zu linken und andersherum. Unter Windows ist es so, dass sich alle Compiler-Entwickler an Microsoft orientieren müssen. Intel wollte aber z.B. nicht die kaputte C++-ABI vom g++ 2.95 übernehmen. Seit g++ 3.4 ist die ABI stabil. Der 4.0 hat nichts geändert, trotz des Wechsels der Majorversion.
> Das stimmt nicht. Nur C++ macht solche Probleme.
Bezug? Ich hatte es doch genau umgekehrt ausgedrückt, also gibt es keinen Widerspruch. Ist das Zitat deswegen nicht der ganze Satz, um einen nicht vorhandenen Widerspruch zu konstruieren? Wozu?
> Intel wollte aber z.B. nicht die kaputte C++-ABI vom g++ 2.95 > übernehmen. > Seit g++ 3.4 ist die ABI stabil.
Kann es sein, dass Du vergisst, dass es zwischen 2.95 und 3.4 eine weitere ABI gab, die, als sie neu war, angeblich auch dauerhaft stabil sein wollte? Wieviele Monate hat sie gehalten?
> The main point of the GCC 3.2 release is to have a relatively > stable and common C++ ABI for GNU/Linux and BSD usage [...]. > Unfortunately this means that GCC 3.2 is incompatible with GCC > 3.0 and GCC 3.1 releases.
"Relatively stable" wurde sie offenbar nicht umsonst genannt.
Ich meine das gar nicht vorwurfsvoll. Ich wünsche mir auch eine stabile ABI, die dann über mehrere Jahre halten soll und hoffe mit jedem inkompatiblen Wechsel, dass sie jetzt endlich mal kommt.
Aber trotzdem muss man sich doch nichts vormachen. "Linux" und "C++" in einem Satz lösen doch immer wieder unangenehme Assizoationen aus, und zwar nicht ohne Grund. Um C++-Bibliotheken werden aufgrund ihrer unverschuldeten Unzuverlässigkeit nicht selten Bögen gemacht.
Du hast behauptet, dass mäßig alte Linux-Binaries auf ner aktuellen Distribution nicht laufen würden, unabhängig von der Programmiersprache. Ich hab hier genug alte Software, die weiterhin funktioniert. Selbst Netscape 4 läuft noch, wenn man ihn wirklich nutzen will.
Ich weiß, dass mit der GCC 3.2 eine neue C++-ABI eingeführt wurde. Das ändert aber nichts daran, dass die g++-3.4-ABI stabil bleiben soll. Ich hoffe, dass sich an der ABI wirklich nichts mehr ändern wird.
Dass C++ derzeit unter Linux eine Katastrophe ist, bestreite ich gar nicht. Siehe auch Opera-Thread.
> Ist es nun endlich möglich bei den LSB-zertifizierten > Distris beliebige Pakete zu installieren?
Nein, das ist nicht möglich. Es ist möglich, LSB-konforme Pakete auf LSB-zertifizierten Distributionen zu installieren. Mehr nicht! Die allermeisten Pakete sind nicht LSB-konform, distributionseigene fast nie und wenn überhaupt, dann nur zufällig, und Pakete aus apt/yum/...-Repositories von Drittverpackern erst recht nicht.
Du scheinst es tatsächlich missverstanden zu haben. Die LSB spezifiziert nur eine Minimalumgebung. Dazu gehören die allerwichtigsten Bibliotheken, nicht aber zum Beispiel die kdelibs. Konkret bedeutet das nichts anderes, als dass ein LSB-konformes Paket die kdelibs statisch linken oder ein eigenes Exemplar davon enthalten muss.
Dies ist bei den allermeisten Paketen, die man in freier Wildbahn findet, nicht der Fall, sondern diese sind so gebaut, dass sie die Bibliotheken benutzen, die auf dem Baurechner vorhanden waren - wer sie auf seinem eigenen System nicht hat, hat eben Pech gehabt.
Bei distributionseigenen Paketen ist es egal und bei distributionsfremden ist es mit dem einfachen rpmbuild, wie es die meisten Verpacker bisher praktizieren, definitiv nicht getan. Solange sich die Linux-Plattform noch mit jährlichen C++-ABI-Wechseln beschäftigt, ist es allerdings auch wirklich zu früh dazu.
- ...die LSB, die Novell und Redhat sich zertifizieren lassen wollen, aber es tunlichst unterlassen, dem LCC beizutreten. UnitedLinux ist tot, beim DCC fehlt Ubuntu. Wie man es auch dreht und wendet: Irgendeiner schießt immer quer. Man kann sich einfach nicht auf ein großen gemeinsames Linux einigen. Das funktioniert einfach nicht.
Naja, da wird sich Microsoft ins Fäustchen lachen und spätestens bei der Werbekampagne für Windows Vista gerät Linux mal wieder ins Hintertreffen, das (Vista/Longhorn) wird man nicht nur im Fernsehen bewundern dürfen (welchen Song kauft MS diesmal?) sondern auch an den Themen in den Kioskzeitschriften. Linux? Fehlanzeige. Gerade wurden hier im Supermarkt wegen fehlender Resonanz die Linuxzeitschriften abbestellt. Linuxwerbung, einen müden Spot von IBM, das wars.
Linux (als Verallgemeinerung von alles Distriburoren/Firmen) wird in diesen zerfretteltem Zustand keinen Meter machen, ungeachtet der Tatsache, das es besser ist. Das LSB oben ist nur ein müdes Lippenbekenntnis der Distributoren, die sowieso ihr eigenes Süppchen kochen!
Ich frage mich, warum die das ganze schon LSB 3.0, obwohls zu LSB 2.0 ja keine wirklich gravierenden Änderungen gibt. Ich fänds besser, wenn die sich z.B. mal an das Chaos im /etc-Verzeichnis bzw. dem persönlichen etc-Verzeichnis - auch versteckte Dateien im "home"-Verzeichnis genannt - annehmen. Das sind meiner Meinung nach die wirklichen Probleme von Linux, bis jetzt scheint LSB ja eher eine Lösung für kommerzielle Software zu sein, ich hatte bisher noch keinen ersichtlichen Nutzen davon.
Aber im April 2004 wurde ja Besserung versprochen.
;)
<
Mahlzeit.
> "Anwendungen, die LSB-konform sind, sollen ohne Neucompilierung auf allen LSB-konformen Distributionen laufen."
So weit mir bekannt ist, läuft eine Gnome/KDE-Anwendung die unter SUSE erstellt nicht ohne Probleme unter Redhat, da die Speicherorte für Gnome/KDE unterschiedlich sind.
Ansonsten hatte ich daneben oft andere Probleme, dass abhängige Bibliotheken anders heißen etc., so dass es im Moment aus meiner Sicht nicht problemlos möglich ist Anwendungen die unter einer Distribution erstellt wurden, unter einer anderen Distribution aus zu führen.
KDE-Anwendungen kann man auch installieren, wohin man will, nur muss man vor dem Start die Variable KDEDIR anpassen. Darum kann sich aber ein Startskript kümmern. Das Mozilla-Startskript setzt schließlich auch LD_LIBRARY_PATH etc. neu, damit die Mozilla-Libs von ld gefunden werden.
> vor dem Start die Variable KDEDIR anpassen.
Fast richtig, KDEDIRS heißt die Variable. KDEDIR war mal und sollte - theoretisch - nicht mehr benötigt werden, aber es kann nie schaden sie doch noch zu setzen, auf den Prefix der kdelibs/kdebase-Installation.
Für zusätzliche Anwendungen reicht aber ein Eintrag in KDEDIRS (und PATH)
naja und kde/gnome/foo wuerde ich sagen gehoert nach /usr. /opt/kde oder wo das andere hintun is zwar nich direkt falsch,aber dafuer sehe ich eigentlich keinen grund...
Lesen! Marsch, marsch...
http://www.livejournal.com/users/udrepper/8511.html
Diskussion auf Slashdot:
http://linux.slashdot.org/linux/05/09/19/1128201.shtml
Mit hinterlistigen Grüßen,
Arny
Läuft da nicht irgendwas falsch, wenn der Standard der Software angepasst wird (anstatt umgekehrt)?
Christian
> der Software angepasst wird (anstatt umgekehrt)?
Könnte man meinen. Vor allem frage ich mich aber, woher die ständige C++-Problematik des GCC überhaupt kommt. Es ist ja nicht das erste Mal. Ist ein Ende abzusehen?
Im Moment führt ja kaum ein Weg daran vorbei, sämtlichen C++-Code bis auf die libstdc++ statisch ins Binary zu linken und den Benutzern alter Distributionen ein Exemplar der libstdc++.so.6 mitzuliefern, wenn man ein Binary erstellen will, das auf allen Distributionen läuft.
Bitte nicht gleich mit "aber man kann doch neu kompilieren, wenn man den Quellcode hat" kommen. Ja, kann man, will aber nicht jeder und außerdem geht es bei der LSB genau darum, es nicht mehr zu müssen, selbst wenn man könnte. KDE-Anwendungen sind beispielsweise praktisch unmöglich für alte und neue Distributionen zu packen. Das kann doch keiner wollen.
Übrigens: Der beschriebene Sachverhalt ist einer der Gründe, weshalb das auf www.openoffice.org angebotene Linux-Binary von OpenOffice.org um ca. 20% größer ist als das Windows-Binary.
> mitliefern ist das kein problem.
Stimmt nicht.
> Ein KDE programm für SUSE 9.3 (gcc 3.3 mit alter ABI)
> läuft ohne probleme auf der 10.0 mit gcc 4 (neue ABI).
Das ist nicht wahr. Jede KDE-Anwendung benötigt die kdelibs in derselben ABI-Version wie die Anwendung selbst. Eine KDE-Anwendung der neuen ABI kann die kdelibs der alten ABI nicht nutzen und eine KDE-Anwendung der alten ABI kann die kdelibs der neuen ABI nicht nutzen.
Es ist unmöglich, dynamisch gelinkte C++-Software unterschiedlicher ABI ein und dasselbe Exemplar einer C++-Bibliothek nutzen zu lassen. Deswegen reicht es eben gerade nicht, die libstdc++ doppelt auszuliefern, sondern man müsste alle C++-Bibliotheken doppelt ausliefern. Dies geht allerdings auch nicht, weil sich die SO-Names der C++-Bibliotheken mit Ausnahme der libstdc++ nicht ändern, da sich nur ihre ABI, nicht aber ihre API ändert.
Fazit: Nein, so leid es mir tut, es ist nicht möglich, was Du vorschlägst. Auch die Parallelinstallation mehrerer gleichnamiger Bibliotheken in verschiedene Verzeichnisse ist kein praktikabler Weg. Falls Du es mir nicht glaubst: Kein Problem. Verfolg einfach die Entwicklung bei Debian oder irgendeiner anderen Distribution, bei Debian sieht man es allerdings besonders deutlich, oder lies hier:
http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html
> Die programme können gleichzeitig gegen beide libs
> linken, daher macht es nichts dass qt/kde libs gegen
> die neue linken und das Programm gegen die alte.
Erstens stimmt das nicht und zweitens wäre es sowieso sinnlos, weil die ABI-Frage keine Frage des dynamischen Linkens gegen unterschiedliche Versionen der libstdc++ ist. Die einzige Lösung besteht darin, sämtlichen C++-Code statisch zu linken, nur die libstdc++ nicht. Die libstdc++ auch noch statisch zu linken, ist sogar kontraproduktiv, weil man sich dadurch eine Abhängigkeit von einer ganz bestimmten glibc-Version einfangen würde, die man sonst nicht hätte.
Das erste "Stimmt nicht" muss ich der Korrektheit halber doch einschränken: Natürlich stimmt es für Programme, die selbst in C++ geschrieben sind und keine C++-Bibliotheken außer der libstdc++ nutzen, insofern ist die Aussage "Stimmt nicht" falsch, es müsste "Stimmt im Allgemeinen nicht" heißen.
Die wichtigsten und interessantesten C++-Anwendungen (KDE, Qt) tun dies jedoch, deswegen stimmt es bei denen tatsächlich nicht. Nochmal zur Verdeutlichung: Das Problem ist NICHT die libstdc++, die ja bekanntlich problemlos parallel installierbar ist, sondern die ABI. Der dynamische Linker kann zur Laufzeit keinen Code unterschiedlicher ABI in ein und denselben Prozess laden.
Deswegen dürfen bzw. können C++-Programme nur Code von ein und derselben ABI enthalten. Es gibt drei Möglichkeiten, damit dies der Fall ist:
- das Programm ist selbst in C++ geschrieben, nutzt aber keine C++-Bibliotheken (nicht der Fall bei KDE- und Qt-Anwendungen)
- das Programm nutzt C++-Bibliotheken und ist statisch gegen diese gelinkt (relativ gut machbar bei Qt, kaum machbar bei KDE)
- das Programm nutzt C++-Bibliotheken und bringt diese selbst mit (relativ gut machbar bei Qt, praktisch ausgeschlossen bei KDE)
Nur als Hinweis: Qt und KDE sind bzw. enthalten die bekanntesten, wichtigsten und meistbenutzten C++-Bibliotheken, sind aber keineswegs die einzigen Beispiele. Wer Zeit hat, kann eine wirklich lange Liste aufstellen. wxWidgets würde zum Beispiel auch auf dieser Liste stehen. Das ändert seine API (API, nicht ABI) und seine SO-Names allerdings so oft, dass man es sowieso statisch linken sollte, wenn Portabilität wichtig ist.
Im prinzip ja, aber: wenn die alte ABI (Compiler UND Spec) Fehler enthält, dann sollten die korrigiert werden. Und da es öfters neue Compilerversionen gibt als neue Specs, werden die Fehler zuerst im Compiler behoben und erst später in den Specs. Und wenn man Glück hat, reicht es bei der Spec, einfach nur die neue ABI des Compilers zu übernehmen.
Was tatsächlich bei der ABI-Änderung ablief, kann ich nicht zuverlässig sagen. Lies die Specs und die gcc-Changelogs. Aber ich glaube mich erinnern zu können daß es da Fehler gab, die behoben werden mussten.
> Fehler enthält, dann sollten die korrigiert werden.
Ich habe auch keine Detailkenntnis über die Ursachen der ständig wiederholten inkompatiblen ABI-Änderungen, aber eines ist und bleibt trotzdem pervers: Und zwar die Tatsache, dass es möglich ist, auf einem Linux-System mit nagelneuen Bibliotheken uralte Windows- und DOS-Binaries zusammen mit Bibliotheken egal welchen Alters auszuführen, nicht aber mäßig "alte" oder auch "zu neue" Linux-Binaries, und zwar unabhängig von der benutzten Programmiersprache.
> Aber ich glaube mich erinnern zu können daß es da Fehler
> gab, die behoben werden mussten.
Fehlerbehebungen sind super, trotzdem stellt sich in jedem Einzelfall immer wieder die Frage, wie man es denn nun konkret anstellt. Ein bekannter Softwarehersteller, der wegen der unüberbietbaren Fehlerhaftigkeit seiner Produkte angeblich seit Jahren kurz vor dem Untergang steht, ist bisher ohne inkompatible ABI-Änderungen ausgekommen, die das Neukompilieren sämtlicher Software in einer bestimmen Programmiersprache erfordern.
Nein, die Lügen gewisser Interessengruppen über angeblich noch viel häufigere ABI-Änderungen sind nicht wahr und auch die wahrscheinlich bald kommende Behauptung, auf dieser Plattform gebe es keine Bibliotheksteilung, ist ebenfalls unrichtig. Komponenten und Bibliotheken werden in großem Umfang zwischen dem Basissystem und den Anwendungen gemeinsam benutzt und bleiben über Jahre hinweg kompatibel.
Über die angebliche Notwendigkeit des ABI-Wechsels beim GCC kann ich mir, wie gesagt, kein Werturteil erlauben, trotzdem bleibt festzuhalten, dass Konkurrenzprodukte, da sind wir uns ganz bestimmt alle einig, auch schwerwiegende Fehler aufweisen, die aber ohne inkompatiblen ABI-Wechsel gelöst werden konnten. Das ist vielleicht etwas schwieriger und kostet möglicherweise auch etwas mehr Geld in der Entwicklung, macht dafür aber einen wesentlich solideren und besseren Eindruck.
Das stimmt nicht. Nur C++ macht solche Probleme.
Die ABI-Wechsel beim g++ haben auch damit zu tun, dass man endlich kompatibel zu allen anderen C++-Compilern sein will. Es soll möglich sein, mit dem Intel C++-Compiler kompilierte Binaries gegen g++-kompilierte Libs zu linken und andersherum.
Unter Windows ist es so, dass sich alle Compiler-Entwickler an Microsoft orientieren müssen.
Intel wollte aber z.B. nicht die kaputte C++-ABI vom g++ 2.95 übernehmen.
Seit g++ 3.4 ist die ABI stabil. Der 4.0 hat nichts geändert, trotz des Wechsels der Majorversion.
Bezug? Ich hatte es doch genau umgekehrt ausgedrückt, also gibt es keinen Widerspruch. Ist das Zitat deswegen nicht der ganze Satz, um einen nicht vorhandenen Widerspruch zu konstruieren? Wozu?
> Intel wollte aber z.B. nicht die kaputte C++-ABI vom g++ 2.95
> übernehmen.
> Seit g++ 3.4 ist die ABI stabil.
Kann es sein, dass Du vergisst, dass es zwischen 2.95 und 3.4 eine weitere ABI gab, die, als sie neu war, angeblich auch dauerhaft stabil sein wollte? Wieviele Monate hat sie gehalten?
> The main point of the GCC 3.2 release is to have a relatively
> stable and common C++ ABI for GNU/Linux and BSD usage [...].
> Unfortunately this means that GCC 3.2 is incompatible with GCC
> 3.0 and GCC 3.1 releases.
Quelle: http://www.gnu.org/software/gcc/gcc-3.2/c++-abi.html
"Relatively stable" wurde sie offenbar nicht umsonst genannt.
Ich meine das gar nicht vorwurfsvoll. Ich wünsche mir auch eine stabile ABI, die dann über mehrere Jahre halten soll und hoffe mit jedem inkompatiblen Wechsel, dass sie jetzt endlich mal kommt.
Aber trotzdem muss man sich doch nichts vormachen. "Linux" und "C++" in einem Satz lösen doch immer wieder unangenehme Assizoationen aus, und zwar nicht ohne Grund. Um C++-Bibliotheken werden aufgrund ihrer unverschuldeten Unzuverlässigkeit nicht selten Bögen gemacht.
Ich hab hier genug alte Software, die weiterhin funktioniert. Selbst Netscape 4 läuft noch, wenn man ihn wirklich nutzen will.
Ich weiß, dass mit der GCC 3.2 eine neue C++-ABI eingeführt wurde. Das ändert aber nichts daran, dass die g++-3.4-ABI stabil bleiben soll. Ich hoffe, dass sich an der ABI wirklich nichts mehr ändern wird.
Dass C++ derzeit unter Linux eine Katastrophe ist, bestreite ich gar nicht. Siehe auch Opera-Thread.
habe ich das richtig verstanden? Ist es nun endlich möglich bei den LSB-zertifizierten Distris beliebige Pakete zu installieren?
Also Debian-Pakete unter SuSE, oder SuSE-Pakete unter Ubuntu?
cu
Nein.
> Ist es nun endlich möglich bei den LSB-zertifizierten
> Distris beliebige Pakete zu installieren?
Nein, das ist nicht möglich. Es ist möglich, LSB-konforme Pakete auf LSB-zertifizierten Distributionen zu installieren. Mehr nicht! Die allermeisten Pakete sind nicht LSB-konform, distributionseigene fast nie und wenn überhaupt, dann nur zufällig, und Pakete aus apt/yum/...-Repositories von Drittverpackern erst recht nicht.
Du scheinst es tatsächlich missverstanden zu haben. Die LSB spezifiziert nur eine Minimalumgebung. Dazu gehören die allerwichtigsten Bibliotheken, nicht aber zum Beispiel die kdelibs. Konkret bedeutet das nichts anderes, als dass ein LSB-konformes Paket die kdelibs statisch linken oder ein eigenes Exemplar davon enthalten muss.
Dies ist bei den allermeisten Paketen, die man in freier Wildbahn findet, nicht der Fall, sondern diese sind so gebaut, dass sie die Bibliotheken benutzen, die auf dem Baurechner vorhanden waren - wer sie auf seinem eigenen System nicht hat, hat eben Pech gehabt.
Bei distributionseigenen Paketen ist es egal und bei distributionsfremden ist es mit dem einfachen rpmbuild, wie es die meisten Verpacker bisher praktizieren, definitiv nicht getan. Solange sich die Linux-Plattform noch mit jährlichen C++-ABI-Wechseln beschäftigt, ist es allerdings auch wirklich zu früh dazu.
beizutreten. UnitedLinux ist tot, beim DCC fehlt Ubuntu. Wie man es auch dreht und wendet: Irgendeiner
schießt immer quer. Man kann sich einfach nicht auf ein großen gemeinsames Linux einigen. Das funktioniert
einfach nicht.
Naja, da wird sich Microsoft ins Fäustchen lachen und spätestens bei der Werbekampagne für Windows Vista
gerät Linux mal wieder ins Hintertreffen, das (Vista/Longhorn) wird man nicht nur im Fernsehen bewundern
dürfen (welchen Song kauft MS diesmal?) sondern auch an den Themen in den Kioskzeitschriften. Linux?
Fehlanzeige. Gerade wurden hier im Supermarkt wegen fehlender Resonanz die Linuxzeitschriften abbestellt.
Linuxwerbung, einen müden Spot von IBM, das wars.
Linux (als Verallgemeinerung von alles Distriburoren/Firmen) wird in diesen zerfretteltem Zustand keinen Meter
machen, ungeachtet der Tatsache, das es besser ist. Das LSB oben ist nur ein müdes Lippenbekenntnis der
Distributoren, die sowieso ihr eigenes Süppchen kochen!
Schön, dass du Recht hast. Nur will das hier nur niemand hören (lesen).
Super! :-)
L00NIX