Linux Programmkompatibilität



  • Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Themen rund um den PC in das Forum Linux/Unix verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Kompilieren ist kein Problem, das Problem ist nur die Form der Pakete.

    Wenn du einfach ein ZIP (oder tar.gz etc.) mit Binaries hast, läuft das überall. So wird zum Beispiel auch Firefox auf mozilla.com angeboten.

    Grenzen: Rückwärtskompatibel sind im Prinzip alle Linux-Versionen bis zu den frühesten. Es müssen allerdings die richtigen Bibliotheken vorhanden sein. Außerdem wurde mit GCC 3.2 die Konvention für C++ geändert, C++-Programme und -Libs müssen also beide mit einer Version ab 3.2 kompiliert sein, oder beide mit einer Version davor.

    Diese Geschichten sind aber alle schon so lange her (mindestens 5 Jahre), dass sie für heutige Distrikompatibilität keine Rolle spielen sollten.



  • Die meisten "Probleme" bekommt man eher wenn man mit Frameworks arbeitet.

    Ich benutze KDE, also Qt, muss aber wegen Firefox, Chromium und noch ein paar anderen Sachen GTK installiert haben.

    Wenn es bei der Installation als Abhängigkeit dabei steht, kein Problem.
    Was dann nur nervt ist der Rattenschwanz den man mitinstallieren muss.

    Allerdings ist das ja in der heutigen Zeit dank großer Festplatten kein Problem mehr.

    Aber ehrlich gesagt, heutzutage irgendwas zu programmieren ohne solch ein Framework ist mörderisch und machen auch nur masochisten. 😉



  • earli schrieb:

    Kompilieren ist kein Problem, das Problem ist nur die Form der Pakete.

    Wenn du einfach ein ZIP (oder tar.gz etc.) mit Binaries hast, läuft das überall. So wird zum Beispiel auch Firefox auf mozilla.com angeboten.

    Wäre schön wenn es so einfach wäre wie du schreibst. Aber die ersten Probleme kommen schon beim Kompilieren. Statisch linken geht mit C++ nicht so richtig.

    Man muss dann viele libs zusammensuchen und mitliefern. Spätestens die libc oder so lässt sich dann nicht mitliefern, weil die an den Kernel gebunden ist.

    Ob es unter einer Distri wirklich läuft, weiß man nur wenn man es dort ausprobiert hat ⚠


  • Mod

    DrGreenthumb schrieb:

    Statisch linken geht mit C++ nicht so richtig.

    😮 Ähh, was?

    Spätestens die libc oder so lässt sich dann nicht mitliefern, weil die an den Kernel gebunden ist.

    Dann muss man zur Not eben eine alte Version der libc linken, da garantiert ist, dass diese mit neueren Kernels arbeiten. Aber die libc kannst du mit relativ gutem Gewissen dynamisch linken (das ist nicht umsonst der Standard) und du musst dich schon sehr anstrengen, um da Probleme zu bekommen.



  • siehe http://www.trilithium.com/johan/2005/06/static-libstdc/

    insbesondere

    Shared data implies that whenever more than one part of a program needs the runtime support, and any of those parts is dynamically loaded, the runtime support needs to be loaded dynamically too. Otherwise, the different program parts would end up with copies of the data rather than one shared instance. That's the reason for putting the language runtime support code in a dynamic library by default.

    und

    You can ask g++ to tell you exactly what steps are involved in linking a C++ program (try the -v flag if you are curious) and invoke a slightly different set of commands in order to link your application with static versions of libstdc++ and libgcc. But integrating that into your own build process is painful, error-prone, and specific to the machine and compiler version you use.

    Es geht halt immer irgendwie... aber es wird sehr ungemütlich. Das meinte ich mit "geht nicht so richtig".

    SeppJ schrieb:

    Spätestens die libc oder so lässt sich dann nicht mitliefern, weil die an den Kernel gebunden ist.

    Dann muss man zur Not eben eine alte Version der libc linken.

    ja, und danach dann alle verwendeten libs auch gegen die alte libc kompilieren.


  • Mod

    Das ist theoretisches Herbeireden eines Problems wo in der Praxis gar keines ist. Du kannst wie gesagt die Runtime ruhigen Gewissens dynamisch linken. Die sind untereinander auch bei unterschiedlichen Versionen trotzdem sehr kompatibel, aufwärts wie abwärts. Es müsste schon eine Uraltversion der Runtime oder eine sehr sehr exotische Distribution vorliegen, damit das nicht mehr funktioniert.



  • SeppJ schrieb:

    Das ist theoretisches Herbeireden eines Problems wo in der Praxis gar keines ist. Du kannst wie gesagt die Runtime ruhigen Gewissens dynamisch linken. Die sind untereinander auch bei unterschiedlichen Versionen trotzdem sehr kompatibel, aufwärts wie abwärts.

    das ist nicht theoretisch herbeigeredet sondern eigene Erfahrung.

    Die ganzen libs ändern sich ständig. Im besten Fall startet das Programm gar nicht erst wegen undefined references. Im schlimmsten gibt die Funktion NULL zurück statt sonstwas.

    Das ruhige Gewissen hast du erst wenn du's ausprobiert hast.

    Dynamisch linken (gegen libs die man nicht mitliefert) ist also gefährlich. Und statisch linken... viel Spaß wenn du (womöglich closed source) Fremdlibs benötigst, die dlopen machen. 👎



  • Man kann auch nachträglich linken damit wer das linker Problem behoben.



  • DrGreenthumb schrieb:

    SeppJ schrieb:

    Das ist theoretisches Herbeireden eines Problems wo in der Praxis gar keines ist. Du kannst wie gesagt die Runtime ruhigen Gewissens dynamisch linken. Die sind untereinander auch bei unterschiedlichen Versionen trotzdem sehr kompatibel, aufwärts wie abwärts.

    das ist nicht theoretisch herbeigeredet sondern eigene Erfahrung.

    Die ganzen libs ändern sich ständig. Im besten Fall startet das Programm gar nicht erst wegen undefined references. Im schlimmsten gibt die Funktion NULL zurück statt sonstwas.

    Das ruhige Gewissen hast du erst wenn du's ausprobiert hast.

    Dynamisch linken (gegen libs die man nicht mitliefert) ist also gefährlich. Und statisch linken... viel Spaß wenn du (womöglich closed source) Fremdlibs benötigst, die dlopen machen. 👎

    Und dafür gibt es Packetmanager, um dafür zu sorgen, dass bei der Installation alle benötigten Komponenten in der richtigen Version vorliegen.

    Statisches Linken verursacht in der Regel mehr Probleme als es löst, und ist besonders in Hinblick auf Sicherheitsprobleme kaum tolerierbar. Es genügt dann nämlich nicht, einfach eine Komponente im System auszutauschen.



  • camper schrieb:

    Und dafür gibt es Packetmanager, um dafür zu sorgen, dass bei der Installation alle benötigten Komponenten in der richtigen Version vorliegen.

    http://www.korrekturen.de/beliebte_fehler/packet.shtml


  • Mod

    besserwisser schrieb:

    camper schrieb:

    Und dafür gibt es Packetmanager, um dafür zu sorgen, dass bei der Installation alle benötigten Komponenten in der richtigen Version vorliegen.

    http://www.korrekturen.de/beliebte_fehler/packet.shtml

    Bitte Zutreffendes ankreuzen:




  • SeppJ schrieb:

    besserwisser schrieb:

    camper schrieb:

    Und dafür gibt es Packetmanager, um dafür zu sorgen, dass bei der Installation alle benötigten Komponenten in der richtigen Version vorliegen.

    http://www.korrekturen.de/beliebte_fehler/packet.shtml

    Bitte Zutreffendes ankreuzen:


    Wäre es eigentlich dann nicht Packagemanager?


  • Mod

    besserwisser schrieb:

    ]Wäre es eigentlich dann nicht Packagemanager?

    Ach, Mist. Touché.



  • Ich nehme an, das Thema ist als solches geklärt, wenn bloß noch über Orthografie gestritten wird?



  • SeppJ schrieb:

    Du kannst wie gesagt die Runtime ruhigen Gewissens dynamisch linken. Die sind untereinander auch bei unterschiedlichen Versionen trotzdem sehr kompatibel, aufwärts wie abwärts. Es müsste schon eine Uraltversion der Runtime oder eine sehr sehr exotische Distribution vorliegen, damit das nicht mehr funktioniert.

    Das halte ich für ein Gerücht.
    Bei der g++ Lib (libstdc++.so.6) reicht schon eine leicht geringere Versionsnummer zwischen Compile- und Laufzeitumgebung aus, um inkompatibel zu werden:
    libstdc++.so.6 version glibcxx_3.4.9' not found
    http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
    Passiert natürlich meist in Umgebungen, in denen man eben nicht schnell mal was Passendes nachinstallieren kann/darf.
    Bleibt meist nur LD_LIBRARY_PATH, von unbedenklicher Kompatibilität kann keine Rede mehr sein.



  • Bin ich denn der einzige, bei dem das bisher immer tadellos funktioniert? Hat eigentlich irgendjemand außer mir mal praktische Erfahrungen gemacht? Vielleicht bin ich ja ein echtes Glückskind, was Versionsnummern angeht, aber ich mag das nicht so recht glauben. Daher bin ich etwas überrascht, wegen der vielen gegenteiligen Links in diesem Thread. Aber ich weiß auch, dass so etwas im Internet immer überproportional repräsentiert wird, da natürlich niemand Artikel da drüber schreibt, wie wunderbar alles funktioniert. Meistens fällt es ja noch nicht einmal auf, dass da überhaupt eine Schwierigkeit gewesen wäre.



  • SeppJ_logout schrieb:

    Bin ich denn der einzige, bei dem das bisher immer tadellos funktioniert? Hat eigentlich irgendjemand außer mir mal praktische Erfahrungen gemacht?

    habe ja schon geschrieben, dass das eigene Erfahrung ist. Da gehts dann mal unter unter Suse 10.2 und unter 10.3 gibts kuriose Abstürze. Oder auch das von Wutz genannte.

    Das es oft gut geht, sieht man ja auch an Programmen wie firefox. Aber auch die haben regelmäßig immer mal wieder eins der genannten Probleme.


Anmelden zum Antworten