vdr-2.4.6 kompiliert mit gcc-11.0.0 nicht

  • Hallo,


    ich versuche den vdr-2.4.6 auf einer zukünftigen Fedora 34 Version mit dem aktuellsten gcc-11.0.0 zu kompilieren, dies schlägt momentan mit

    folgenden Meldungen fehl:



    laut Klaus Schmidinger wurden diese Abfragen damals von Gerald Berwolf bzw. Jasmin Jessich eingebaut,

    um die Templates für Plugins abschalten zu können, die die STL benutzen.


    Der VDR-2.4.x lässt sich mit folgendem Patch (Notlösung) kompilieren:


    Gibt es jemand hier im Forum, der mir hier eine saubere Lösung vorschlagen kann im Zusammenhang mit gcc-11.0.0.


    Viele Grüße

    Martin

    Gruß MartinKG

    Fedora33 x86_64 Gnome Desktop vdr 2.4.4 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

  • Das ist meine momentane Lösung: habe jetzt festgestellt, dass ich bei meinen vdr Plugins das flag C++14 mitgegeben habe (- Force C++14 as this code is not C++17 ready), damit lässt sich der vdr wieder kompilieren.

    Code
    1. make CFLAGS="%{optflags} -fPIC" CXXFLAGS="-std=c++14 ..."

    Gruß MartinKG

    Fedora33 x86_64 Gnome Desktop vdr 2.4.4 mit vdr-softhddevice plugin.

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400

  • Kommt drauf an wo das "max" vorkommt. Das Problem ist hier das Klaus aus bisher unbekannten Gründen nicht auf das "max" aus der C++ Standard Library zurückgreift und stattdessen das Rad neu erfindet.


    Ein einfacher Patch um diesen Probleme dauerhaft zu eliminieren wäre Umstellung des VDR selbst auf "std::max" und Löschen der eigenen Implementierung.

  • Stimmt, die Macros Templates min und max sind überholt.


    [edit]korrekter Hinweis.[/edit]

  • Hi,

    bei Gentoo kommt gcc-11 nun auch auf uns zu. Wie lösen wir das am vernünftigsten?


    Ideal wäre eine Lösung die auch mit gcc-9/10 funktioniert, UND ermöglicht daß nicht in allen Plugins rumgepatch werden muss.


    Gerade fällt mir ein, "swap" wird auch moniert. Kann das durch "std::swap" ersetzt werden?

  • In tools.h werden die Macros __STL_CONFIG_H, _STL_ALGOBASE_H und _MOVE_H abgefragt, um zu erkennen, ob Header-Files der stdlib inkludiert wurden. Für VDR selber ist dies nicht der Fall, so dass also keines dieser Macros definiert sein sollte. Warum dies nun in gcc-11 plötzlich doch der Fall ist, weiß ich nicht.

  • Die Frage ist aber doch warum immer wieder der Kampf ausgefochten wird irgendwie die "Spezial-Versionen" im VDR zu "verteidigen". Warum nicht entsorgen und die "Standard-Versionen" nutzen? Ich frage mich ob das nicht sogar ein einfacher GCC11-Fix wäre. Passendes Include oben rein und die Defines so verbiegen das sie direkt auf std::max und std::min zeigen.


    Wegen dem "woher kommen die Defines" würde ich einfach mal in den Raum stellen das eine der vielen anderen Includes vielleicht seinerseits bei GCC 11 auf ein STL-Feature aufsetzen, die entsprechende ".h" inkludiert und so das Define global reinziehen. Ist halt irgendwo in Kampf gegen die Programmiersprache wenn man Standardfeatures mit der Brechstange nicht haben will.

  • Vorschlag:

    Plugins, die STL verwenden, müssen dann halt DISABLE_TEMPLATES_COLLIDING_WITH_STL definieren.

  • Warum nichtmal wenigstens einen Satz zur Frage warum der VDR eigene Spezial-Implementierungen hat? Und wenn es "gefallen mir besser" ist, dann schreib halt einfach das.


    Ich will ja nicht sagen das ignorieren sehr unhöflich ist, aber ich finde ignorieren eigentlich schon sehr unhöflich. :|

  • Vorschlag:

    Plugins, die STL verwenden, müssen dann halt DISABLE_TEMPLATES_COLLIDING_WITH_STL definieren.

    kann man das auch bei 2.5.3 anwenden? Hab ja das gleiche Problem bei Fedora 34.

  • M-Reimer VDR hat (fast) von Anfang an swap(), min() und max() selber implementiert und hat STL weder benutzt noch gebraucht. Als dann Plugins dazukamen, gab es einige Autoren, die in ihrem Code gerne STL verwenden (was ihr gutes Recht ist). Aber anscheinend verträgt sich das nicht mit den Templates in tools.h, daher habe ich einige Macros abgefragt, um zu testen, ob vielleicht ein STL-Header-File inkludiert wurde, und dann die störenden Templates deaktiviert. Vielleicht hätte ich von Anfang an nur DISABLE_TEMPLATES_COLLIDING_WITH_STL benutzen sollen, aber ich wollte es den Plugin-Autoren halt einfach machen.


    Eigentlich sollte es sich aber doch gar nicht "beissen", wenn in tools.h die Templates definiert werden, und in einem Plugin z.B. statt min() std::min() benutzt wird. So ganz verstehe ich nicht, was da eigentlich schief läuft...

  • md_berlin Sie erfüllen den gleichen Zweck. Selbst wenn sie nicht exakt gleich sind sollten sie sich schon sehr ähneln.


    Ich hab jetzt einfach mal mitgenommen das das im VDR eben schon immer so war und dann "never change a running system".

    Wäre es mein Projekt würde ich es als Herausforderung sehen mal zu schauen was C++ mittlerweile "nativ" bietet und wie viel eigener Code damit raus könnte. Dafür spricht nicht nur das Argument, dass die "nativ" verfügbaren Funktionen über viele Projekte genutzt werden, und so Optimierungen/Bugfixes schneller umgesetzt werden, sondern auch der "Wiedererkennungswert". Ein neuer "Beitragender" findet sich, wenn er C++ kann und einen Standardtypen sieht, einfach direkt zurecht.


    Aber ist letztlich die Entscheidung von kls was ihm wichtiger ist. Mir kann es weitgehend egal sein weil ich auch in Zukunft nicht im größeren Stil Plugins entwickeln will.

  • Solange niemand ein 'using namespace std' benutzt, sollten 'min' und 'std::min' ohne macros drum herum friedlich coexistieren.


    Anscheinend ist eher das Problem, dass es das magische _STL_ALGOBASE_H nicht gibt und damit weder min noch std::min.

    Wo kommt das her, doch nicht etwa aus einer speziellen Implementation der STL?


    Die saubere Lösung könnte btw auch sein, betroffene Plugins zu fixen, anstatt hier neue Verrenkungen zu bauen.

  • Lässt sich fixen.