Binaries weitergeben

Hallo,

Wenn ich QT4 auf meinem Suse 9.3 System kompiliere. Kann ich die libs und die includes weitergeben? Oder anders gefragt: Auf welchen Systemen könnten diese Dateien direkt verwendet werden?
- ein Rechner mit Suse 9.3
- Suse 9.x
- Suse 10.x
- andere (nicht Suse) Linux Distributionen?

Wovon hängt das im einzelnen ab?

Danke, Martin

ich denke mal das hängt in erster linie von systemspezifischen compileroptionen ab - falls du also zb das march flag angegeben oder andere angaben in der richtung gemacht hast...

Martin Baumann schrieb:

Wenn ich QT4 auf meinem Suse 9.3 System kompiliere. Kann ich die libs und die includes weitergeben?

Zum Vergrößern anklicken....

Nein, jedenfalls nicht "einfach so" und ohne Weiteres.

Martin Baumann schrieb:

- ein Rechner mit Suse 9.3

Zum Vergrößern anklicken....

Sollte gehen, sofern man nicht ganz eigenartige Sachen macht.

Martin Baumann schrieb:

- Suse 9.x

Zum Vergrößern anklicken....

Nein. Ältere glibc-Version als das System, auf dem gebaut wurde -> geht nicht.

Martin Baumann schrieb:

- Suse 10.x

Zum Vergrößern anklicken....

Nein. Neuere GCC-Version mit anderer ABI -> geht nicht.

Martin Baumann schrieb:

- andere (nicht Suse) Linux Distributionen?

Zum Vergrößern anklicken....

Nur wenn das System dieselben oder kompatible Bibliotheken und dieselbe oder eine kompatible GCC-Version hat.

Martin Baumann schrieb:

Wovon hängt das im einzelnen ab?

Zum Vergrößern anklicken....

1. Von der glibc-Version.

Die glibc ist die Mutter aller Bibliotheken und wird ständig erweitert. Erstellt man ein Binary auf einem System mit einer neuen glibc und versucht es auf einem System mit einer älteren glibc auszuführen, wird es im Allgemeinen nicht funktionieren. Umgekehrt geht es dagegen meistens. Man sollte also immer das ältestmögliche System zum Erstellen von Binaries verwenden.

2. Von der GCC-Version.

Der GCC hat die unangenehme Eigenschaft, seine ABI in Bezug auf C++ regelmäßig zu ändern. Das ist keine Frage der Distributionen, sondern der GCC-Versionen an sich. Da es sich bei Qt um eine C++-Bibliothek handelt, wird man bei Qt immer wieder mit diesem Problem konfrontiert sein. Lösen kann man es eigentlich nur, indem man für jede Gruppe von Distributionen mit jeweils untereinander kompatiblen GCC-Versionen eigene Binaries anbietet. So macht das zum Beispiel Opera.

GCC 3.2 und 3.3 sowie GCC 3.4 und 4.0 sind jeweils untereinander kompatibel. SuSE 9.3 hat GCC 3.3, SuSE 10.0 hat GCC 4.0, also sind die beiden leider nicht kompatibel.

3. Von weiteren Bibliotheken.

Deine Anwendungen hängen sicherlich nicht nur von Qt ab, sondern von mehr oder weniger vielen weiteren Bibliotheken. Es gibt Bibliotheken wie z.B. zlib und libpng, die ihre ABI sehr selten ändern, wenn überhaupt irgendwann. Es gibt aber leider auch andere Bibliotheken, die von Binärkompatibilität wenig halten wie z.B. flac. Sofern man solche Bibliotheken nutzt, hat man ein Problem, das man eigentlich nur lösen kann, indem man diese Bibliotheken auch noch mitliefert.

4. Vom Aufbau des Dateisystems.

Im Linux-Bereich ist es oft üblich, Pfade zu Dateien wie z.B. Grafiken, Konfigurationsdateien u.ä. fest in die Binaries einzukompilieren. Das ist sehr einfach, kann aber unangenehme Probleme verursachen, wenn man Binaries weitergeben will. Nicht jeder hat KDE in /opt/kde3 installiert, umgekehrt möchte aber auch nicht jeder alles in /usr auf einem Haufen haben. Von diesem Problem sind Anwendungen, die keine derartigen Dateien brauchen, nicht betroffen, die meisten grafischen Anwendungen brauchen aber sehr wohl diverse externe Dateien und müssen auch wissen, wo sich diese befinden.

Generell kann man sagen, dass es nicht einfach ist, Binaries zu erstellen, die auch auf anderen Systemen laufen. Unmöglich ist es allerdings auch nicht, wie Mozilla, OpenOffice.org und andere Beispiele zeigen.

Es geht begrenzt. Die meisten C-Programme von SUSE 10.0 laufen auch auf 9.3 (=> my repo), bei C++ dagegen ist das nicht so einfach, da unter 10.0 die libstdc++.so.6 zum Einsatz kommt, 9.3 aber nur libstdc++.so.5 hat.

traffic schrieb:

Nicht jeder hat KDE in /opt/kde3 installiert,

Zum Vergrößern anklicken....

*evel grin* ich kenn nur Suse, die den Scheiß macht, dass Pakete nach /opt geschrieben werden

@TeXpert: Im Jahre 2006 macht das tatsächlich nur noch SuSE, in der Vergangenheit haben es etliche andere Distributionen (Mandrake, Slackware) aber auch so gemacht (um genau zu sein, hat SuSE es von Slackware so übernommen) und zweitens ist dieser "Scheiß" mit /opt gar nicht das eigentliche Problem, weil man, selbst wenn man den "Scheiß" mit /opt vermeidet, genau dasselbe Problem früher oder später mit /usr und /usr/local hat. Ob man nun zwei Installations-Prefixe hat, die sich beißen, oder mehr als zwei, ändert nichts am grundsätzlichen Problem.

Der "Scheiß" mit /opt wird übrigens demnächst abgeschafft, sinnvollerweise aber erst mit KDE4, weil KDE4 sowieso nicht kompatibel zu KDE3 sein wird und eine Umstellung zum jetzigen Zeitpunkt deshalb irgendwie daneben wäre.

Nein, so einfach ist das nicth,

/usr und /usr/local haben einen deutlichen Unterschied. die Distri-Pakete kommen nach /usr und die "selbst" installierten nach /usr/local eine Distri, die meine Installationen in usr/local überschreibt oder aktualisieren würde ist Schrott.

und in /opt "darf" eine Distri etwas installieren... ist aber IMHO ein deutliches Zeichen dafür, dass ein Paket nicht sauber integriert ist.

TeXpert schrieb:

Nein, so einfach ist das nicth, [...]

Zum Vergrößern anklicken....

Sicher nicht?

Ich erstelle ein Binärpaket einer KDE-Anwendung, die irgendwelche anderen KDE-bezogenen Dateien benötigt und auch wissen muss, wo diese liegen.

Situation SuSE vs. Nicht-SuSE:

Ich weiß nicht, ob diese anderen Dateien - welche auch immer das sein mögen - in /opt/kde3 oder anderswo liegen, weil ich nicht weiß, ob das Zielsystem SuSE oder Nicht-SuSE ist.

Situation irgendeine Distribution vs. dieselbe Distribution:

Ich weiß nicht, ob diese anderen Dateien - welche auch immer das sein mögen - in /usr oder /usr/local liegen, weil ich nicht weiß, ob die andere Anwendung, zu der die benötigten Dateien gehören, mit dem Paketmanager oder von Hand installiert wurden.

Wo ist der Unterschied? Es geht bei diesem Beispiel nicht ums Überschreiben, sondern ums Finden.

TeXpert schrieb:

ist aber IMHO ein deutliches Zeichen dafür, dass ein Paket nicht sauber integriert ist.

Zum Vergrößern anklicken....

Die Pakete sind schon integriert, teilweise sogar besser als bei anderen Distributionen. Manche Distributionen (Mandriva... :roll "vergessen" sogar, /usr/local zu PATH, zu /etc/ld.so.conf, zu PKG_CONFIG_PATH usw. hinzuzufügen, bei SuSE hatte ich so ein Problem dagegen nie. GNOME-Anwendungen müssen z.B. keineswegs nach /opt/gnome installiert werden. Sie würden dorthin gehören, aber /usr/local und /usr sind genauso in alle Suchpfade integriert (wirklich alle, einschließlich derer für Themes, gstreamer-plugins, bonobo-Komponenten usw.).

Einzelpakete kommen auch bei SuSE nicht mehr nach /opt, sondern nur:

- KDE (wird sich ändern)
- GNOME (wird sich ändern)
- Mozilla-Anwendungen (Pläne sind mir unbekannt)

Warum Pakete schlechter integriert sein sollten, wenn sie nach /opt installiert werden, verstehe ich nicht ganz. Am Beispiel Mozilla: Was für einen Unterschied macht es, ob eine Mozilla-Anwendung in /opt installiert ist oder nicht? Wo sie am Ende zu finden sein wird, weiß sowieso keiner, weil jede Distribution sowieso ihre eigene Meinung dazu hat: Einige verwenden /usr/lib/$NAME-$VERSION, andere nur /usr/lib/$NAME, manche spalten das Paket auch auf und verteilen die Dateien über /usr/lib und /usr/share, bei manchen ist $NAME für Firefox gleich firefox, manchmal aber auch mozilla-firefox oder MozillaFirefox, $VERSION ist manchmal dreistellig, manchmal aber nur zweistellig, manchmal ist ein Symlink ohne $VERSION vorhanden, der auf die neueste oder die standardmäßig zu verwendende Version zeigt, manchmal aber auch nicht usw...