GCC bauen, wie macht man's richtig?

  • Hallo,

    das bei mir aktuelle *bian-Paket der GCC ist die 4.6. Aus diversen Gründen möchte ich gerne auf die Version 5.2 upgraden. Also habe ich mir die Sourcen besorgt, und im Moment tickert im PuTTY-Fensterchen nebenan "make all" vor sich hin.

    Nun ist meine Frage, wenn der Build durchgelaufen ist, ist es dann in irgendeiner Weise sinnvoll, die Sourcen nochmals mit dem dann upgegradeten Compiler neu zu bauen, oder ist ein 5.2er-gebaut-mit-dem-4.6er genauso gut wie ein 5.2er-gebaut-mit-dem-5.2er?

    LG
    Carsten

    "Wer nur Nägel kennt, hält jedes Stück Materie für einen Hammer."
    (einschließlich mir)

  • Hi Carsten,

    also noch mal übersetzen ist imho Unfug ...
    Was ich aber zu bedenken gebe: wenn der gcc-5.2 für Raspbian noch nicht verfügbar (über die Paket-Verwaltung installierbar) ist, dann ist er wohl auch noch nicht dafür freigegeben.
    Kann also gut sein, dass der 5.2er Compiler noch Bugs hat oder irgendwelche Probleme verursacht ...

    cu,
    -ds-

  • Hi Dreamshader,

    danke für Deine Antwort. Wie gesagt, ich habe Gründe, dass ich den 5.2er haben will. Also vor allem einen 5.x. Ich will eine Stimm-Erkennungs-Suite übersetzen, und der Autor schreibt in den READMEs, dass ein Build mit einem 5.x Performance-Probleme ausbügelt. Und die habe ich mit einem 4.6er-Build tatsächlich ganz massiv, zumal ich die Lib noch in einem Mono-Wrapper verpacke.

    Aber immo scheitert der Build an "bits/predefs.h". Erstmal gucken, wo ich das passende Zeug her kriege :)

    LG
    Carsten

    "Wer nur Nägel kennt, hält jedes Stück Materie für einen Hammer."
    (einschließlich mir)

  • dreamshader: Mit verlaub, das ist Unsinn. Die Paketversion haengt mit den Lebenszyklen der jeweiligen Distribution zusammen. Das Freeze-Date fuer Jessie war vor 2 Jahren - seit dem ist zB der C++14-Standard verabschiedet, und dafuer braucht man halt einen neueren Compiler. Der hat aber deswegen nicht mehr Bugs als der alte.

    R2Pi: wenn auch ein GCC 5.1 reicht, wuerde ich einfach zu Ubuntu Mate greifen, der ist da schon dabei - das sollte deutlich schneller gehen.

    Und einen Grund, das nochmal zu bauen, kann ich nicht erkennen - wenn der Code uebersetzbar ist mit einem aelteren Compiler, dann sollte das auch kein Problem sein. Letztlich ist ein self-hosted Compiler ja notwendigerweise IMMER mit einer aelteren Version seiner selbst gebaut ;) Und ich wuerde erwarten, dass das Build-System einen check hat, ob der verwandte Compiler funktioniert oder nicht. Wenn das also durchgeht - alles gut.

  • Hi,


    dreamshader: Mit verlaub, das ist Unsinn. Die Paketversion ...
    ...


    ich weiss nicht ... vielleicht reden wir da aneinander vorbei, aber ich habe noch nie einen gcc selbst übersetzen müssen ... der wurde immer nach und nach auf den neuesten Stand gebracht.
    Ich musste sogar den Compiler schon "downgraden" weil der aktuell installierte nicht zu den Kernelmodulen passte.

    Und btw: C++14 ist schon ab gcc-4.8 drin ...

    cu,
    -ds-

  • @__deets__: Na ja!

    Also erstmal werde ich nicht von meinem heißestens geliebten MiniBIAN auf Ubuntu... downgraden ;). Meine Odyssee durch Linux-Distros ist schon zu lang, als dass ich das noch fortsetzen möchte, erst Slackware, dann RedHat, dann Fedora, dann mit viel Kopfweh auf Debian, drum auch das MiniBIAN auf dem RPi. Irgendwie bin ich ja so ein Spagat-Mensch, weil ich mit Microsoft (.NET) mein Geld verdiene, drum auch Mono, und im Herzen ruft bei Ubuntu alles "Uh, bunt, du!" Vielleicht bin ich da aber auch einfach total Oldschool, Unix ist für mich Server, Daemons, GCC, Bash-Scripte, vielleicht noch Perl, aber sicher nicht Klicki-Bunti, und zugleich hacke ich meinen RPi-Code im wundervollen Visual Studio zusammen auf nem Samba-Mount. Das erste Linux, das ich hübsch fand, war Android, aber soll mir jetzt mal niemand sagen, dass Google "besser" wäre als Microsoft in Sachen Datensammelwut. Für mich ist Linux "was für die Sicherheit" und Windows "was fürs Auge". Finde mich krude, aber es ist so ;)

    Wieso ich die ursprüngliche Frage gestellt habe, ist das README der Suite, die ich eigentlich übersetzen will. Wenn der Autor sagt, dass der 5.x Performance-Probleme beseitigt in seiner Suite, gehe ich einfach davon aus, dass ein "5.2er-von-einem-5.2er-übersetzt" schneller rennt als ein "5.2er-der-von-einem-4.6er-übersetzt" wurde.

    Und wenn ich mich richtig erinnere, war eine der großen Maximen der GCC ja immer, dass man die GCC mit der GCC bauen kann.

    LG
    Carsten

    "Wer nur Nägel kennt, hält jedes Stück Materie für einen Hammer."
    (einschließlich mir)


  • ich weiss nicht ... vielleicht reden wir da aneinander vorbei, aber ich habe noch nie einen gcc selbst übersetzen müssen ... der wurde immer nach und nach auf den neuesten Stand gebracht.
    Ich musste sogar den Compiler schon "downgraden" weil der aktuell installierte nicht zu den Kernelmodulen passte.

    Mir ging es um deine Aussage, der Grund dafuer, dass eine bestimmte Paketversion nicht verfuegbar ist, liegt darin, dass sie zu fehleranfaellig ist. Solange man keine rolling distribution verwendet, sind diese Versionen festgetackert. Solange man also seine Distribution nicht upgradet (oder wechselt), bleibt die stehen. So kenne ich das jedenfalls seit Jahren von Debian & Ubuntu.

    Und laut https://gcc.gnu.org/projects/cxx1y.html sind nur einige C++14-Features in GCC 4.8 drin, und viel wichtiges erst in 5.x.
    Automatisch zusammengefügt:


    Wieso ich die ursprüngliche Frage gestellt habe, ist das README der Suite, die ich eigentlich übersetzen will. Wenn der Autor sagt, dass der 5.x Performance-Probleme beseitigt in seiner Suite, gehe ich einfach davon aus, dass ein "5.2er-von-einem-5.2er-übersetzt" schneller rennt als ein "5.2er-der-von-einem-4.6er-übersetzt" wurde.

    Dieser Schluss ist so nicht haltbar - eine Stimmanalyse verlangt nach Vektorisierung, die mag sich verbessert haben in 5.2 - aber das compilieren von C++ ist eine ganz andere Aufgabe. Ich wuerde das also nicht machen. Aber hey, deine Zeit :) Nur wenn es dir um Compilierzeiten geht, dann wuerde ich eh nach einem Crosscompiler schielen - dein Desktopprozessor schlaegt den PI selbst unter Wasser & mit angezogener Handbremse.

  • Aha ...


    ...
    Mir ging es um deine Aussage, der Grund dafuer, dass eine bestimmte Paketversion nicht verfuegbar ...
    ...

    na siehste ... so kanns gehen. Ich hab' ja nur gesagt, dass er wohl (noch) nicht (explizit) freigegeben ist (kommt sicherlich irgendwann). Das hat ja erst mal mit Fehlern nix zu tun ;)

    cu,
    -ds-

  • Na ja, aktuell am köcheln ist ja schon GCC 6.x, nur mal so angemerkt ;)

    Ganz ehrlich glaube ich nicht an die Verwanztheit eines neuen Releases, sondern eher daran, dass eine "Open Community", quasi Ehrenamtliche, halt kommt, geht, krank wird, Urlaub macht, wie es ihr beliebt. Die "Open Community" ist kein Arbeitgeber. Und wenn der Maintainer einer bestimmten Distro heute Lust hat, der Maintainer einer anderen Distro aber gerade seine Beine im Mittelmeer schaukelt, kriegt die eine Distro das Update halt schneller als die andere Distro. So ist eben auch das ganze "Open Source"-Zeug.

    Wie schon geschrieben, für den Hobby-Bereich finde ich das alles ganz toll, was da so alles passiert, wie Ideen sich plötzlich zu Konzepten ausbreiten etc etc. Im Beruf möchte ich aber einfach den Hörer abnehmen, die Kurzwahl drücken und mit "meinem" Service-Fritzen verbunden sein, der einfach da ist. Und was immer man an bösen Dingen Microsoft nachsagt, wenn man die richtigen Nummern und Email-Adressen hat, ist das eine Rundum-Sorglos-Verpflegung. Kostet, aber jo. dafür kriegt man auch Leistung. Mit Microsoft macht man eben nur EINEN Vertrag, und der funktioniert. Mit der "Open Community" macht man gar keine Verträge, sondern kann nur hoffen und im Zweifel auch noch das Beten anfangen. Stichwort "MySQL". Wem gehört der Kram gerade eigentlich? ^^

    Auch wenn das niemanden interessieren mag, für mich persönlich liegt der Fehler in der allerersten Formulierung der GPL, in der die kommerzielle Nutzung geduldet wurde.

    "Wer nur Nägel kennt, hält jedes Stück Materie für einen Hammer."
    (einschließlich mir)

    Einmal editiert, zuletzt von R2Pi (17. November 2015 um 19:27)

  • Dreamy, es ist wirklich Unsinn den du da erzählst. Auch Freigegebene Versionen werden nicht unbedingt als Paket aufgenommen, wenn es keine besonderen Gründe hat, denn jedes weitere aufgenommene Paket bedeutet mehr Pflegearbeit (Sicherheutsupdates, Bugfixes etc). Denn die alte Version (Wir reden ja von Major-Releases, da wird nicht ersetzt sondern hinzugefügt, daher die Versionsnummern in den Paketnamen) muss wegen Kompatiblitäten erhalten bleiben.

    Und ich kann mit Überzeugung sagen: Ein mit 4x übersetzter GCC ist genauso "richtig" wie ein mit 5.x übersetzter GCC. Die Geschwindigkeit kann besser sein, aber vermutlich nicht merkbar. Das spielt sich (wie bereits richtig von deets gesagt) in speziellen Ecken ab, die halt gerade für dein Sprachding praktisch sind.

    Was die Aussage angeht, dass Compiler auf Prinzip mit einer älteren Version gebaut werden müssen:
    Der erste Compiler muss natürlich sogar in einer anderen Sprache gechrieben werden, denn es gibt ja noch kein Programm in der neuen Sprache... auch keinen Compiler...
    Dieser erste Compiler kann auch sehr langsam sein und unsauberen Code generieren, Hauptsache der generierte Code ist korrekt.
    Wenn man dann einen Compiler in der neuen Sprache schreibt, dann macht man es "richtig". Also ein sauber entwickelter, schneller Compiler der auch guten Code erzeugt. Aber nicht richtiger, nur besser.
    Genauso kann man es natürlich auch mit der Version machen. Wenn die GCC-Leute eine super Verbesserung in ihren Compiler einbauen, der das kompilieren wesentlich verbessert, dann werden sie den neuen Compiler auch per zweitem Durchlauf mit sich selbst kompilieren um diese Vorteile zu nutzen.
    Aber wie gesagt: Das ist sehr wahrscheinlich ein minimaler Unterschied und zufällig in deinem Anwendungsfall gerade nötig.


  • Dreamy, es ist wirklich Unsinn den du da erzählst. Auch Freigegebene Versionen werden nicht unbedingt als Paket aufgenommen, ...


    Sagt wer?
    Steht wo?
    Du hast doch sicher auch eine belastbare Quelle für diese Aussage, oder?

    Zitat


    ...
    GCC 5 was released in April 2015, and is available in Debian unstable. There are again the usual quirks with new standards versions and older software, and as a major change, the update / introduction of a new libstdc++ ABI.
    ...


    Quelle
    so, wie ich gesagt hatte, ist es ja wohl ... solange der gcc in Debian unstable ist, wird er wohl auch nicht für Raspbian oder Jessie freigegeben ;)
    btw: der letzte aktuelle gcc für Linux ist 4.9 ... der nächste Release ist gleich 5.2 (so er dann für das jeweilige Linux released ist) ...

    Manchmal seid ihr einfach nur anstrengend ;)


    bis denne dann,
    -ds-

  • Dreamshader, bitte beschäftige dich nicht nur mit Einzelzitaten, dein ganzer Beitrag macht keinen Sinn. Debian-unstable ist KEINE Sammlung von unfertigen Programmen sondern eine nicht finale Zusammenstellung die irgendwann den stable-stand erreichen soll. Die Zusammenstellung, nicht die enthaltenen Programme.
    Dabei wird nach Debian-Manier darauf geachtet dass die enthaltene Software auch wirklich stabil läuft. Aber du vermischt (mal wieder) verschiedene Arten und Bedeutungen sowie Ebenen von unstable massiv und erzählst einfach nur Sch***!
    Ich kann du kein Beispiel für meine "Behauptung" nennen, denn bei jedem Beispiel wirst du aufgrund dessen, dass es nicht aufgenommen ist sagen, es sei instabil. Wie das funktioniert steht durchaus irgendwo in den Debian-Richtlinien. Die darfst du gerne selbst lesen, so viel Schwachsinn wie du dazu erzählst wäre das auch eine gute Idee.

  • Also ich weiss nicht ..


    ...
    Debian-unstable ist KEINE Sammlung ...


    hab' ich doch gar nicht behauptet ...


    ...
    ... dass die enthaltene Software auch wirklich stabil läuft. Aber du vermischt (mal wieder) verschiedene Arten und Bedeutungen sowie Ebenen von unstable massiv und erzählst einfach nur Sch***!


    sorry, aber auch das hab' ich niemals behauptet ....


    ... Die darfst du gerne selbst lesen, so viel Schwachsinn wie du dazu erzählst wäre das auch eine gute Idee.


    Also ich glaube, Du bringst da was durcheinander ...
    Ich hab' lediglich gesagt, dass der gcc im unstable branch ist und dass er, solange dieser branch eben unstable ist, wohl nicht über die Paketverwaltung installiert werden kann ...
    Aber ich glaub, ich lass es ... scheinbar verstehst Du alles so, wie Du es verstehen willst und nicht so, wie es dasteht ...
    Eine andere Erklärung hab' ich nicht dafür, dass Du mir Dinge in den Mund legst, die ich so niemals gesagt/geschrieben habe.

    cu,
    -ds-


  • Damals(tm) war Linux toll, weil in Sachen Sicherheit es genug Paranoiker gegeben hat, die jede Kernel- und Treiber-Codezeile mit Tests überzogen hat. Heute ist es, wie ich in genau diesem Thread hier gelernt habe, wohl so wie in der Apple-Community: "Es ist Linux, drum ist es besser, und wenn Xyz sagt, dass ein Modul cool ist, ist das so. Die PTB haben immer Recht!" Blinder Gehorsam. Früher hatte der Führer einen Scheitel und ein kleines Bärtchen. Heute ist es ein Pinguin.

    Sagte der Mann, der "mein MiniBAN ist das beste!!!!1111roelfdroelf" rief... finde den Widerspruch ;)

    Und was deine "Analyse" mit der Diskussion ueber die Paketierungsgewohnheiten von diversen Linux-Distributionen zu tun hat ist mir auch nicht klar.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!