Kompilieren von xmltv2vdr schlägt fehl

  • Hallo,


    mit aktuellem gcc bekomme ich folgenden Fehler, der dann eine Reihe von Folgefehlern nach sich zieht:



    Wie kann man das reparieren?

  • Was ist bei Dir der aktuelle gcc?


    Hast Du den letzten GIT Stand von xmltv2vdr (20.03.2017)?

    HowTo: APT pinning

  • Hi,


    mit aktuellem gcc bekomme ich folgenden Fehler

    mit gcc-7(7.2.0) unter Ubuntu 18.04(bionic) läuft das Build durch - GIT xmltv2vdr commit: Changed code for c++11 compatibility

    ...Arch ist wohl Version 7.2.1


    Gruss

    Wolfgang

  • mit gcc-7(7.2.0) unter Ubuntu 18.04(bionic) läuft das Build durch

    Ja, eben ...

    HowTo: APT pinning

  • Ich denke da spielt dieser Patch für das Makefile mit hinein, der gnu++98 als C++ Standard setzt: https://github.com/VDR4Arch/vd…r_newmakefile_v2.diff#L78


    Wenn man das auf -std=c++11 setzt, hängt es an anderen Stellen - so baut es zumindest (vielleicht kann da noch jemand drüber schauen, der C++ besser beherrscht und das Plugin tatsächlich nutzt):

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von seahawk1986 () aus folgendem Grund: cast zu char statt zu signed char im Patch

  • Ich habe den genannten Patch jetzt auch schonmal ganz rausgelassen, komme aber auf genau die von seahawk1986 genannten Fehler.


    Gibt es denn irgendeinen C++-Standard mit dem es ganz ohne "Fixen" wieder kompiliert? Eigentlich hält sich mein Interesse daran, fremden Code ganz zu machen, in Grenzen. Ich selber nutze das Plugin zudem auch nicht. Brauche es nur für den VDR von einem Bekannten.

  • seahawk1986 Kannst du mir erklären warum du beim Type-Casting zwischen "unsigned" und "signed" variierst? Wäre nicht "unsigned" generell OK?


    Allgemeine Frage: Warum braucht man den Mist überhaupt? Der Compiler kann doch garnicht so doof sein nicht zu wissen, dass er das, was ich ins Array direkt zuweisen will, natürlich in dem Format ist, das das Array selbst hat. Wozu soll ich z.B. bei einem Array dem ich 100 Elemente zuweise jetzt 100 mal eine Zahl nach char casten?

  • Sind die Makefile Anpassungen ArchLinux spezifisch?


    Wenn nein, könntet Ihr ja mal ein bzw. beide Patches über vdr-developer einreichen ... ist nicht so, das Jochen gar nimmer antwortet, sonst gäbe es z.B. den letzten Commit auch nicht ... ;)


    Regards

    fnu

    HowTo: APT pinning

  • Die Makefile-Anpassungen sind von Copperhead und ziehen das alte Makefile auf den neuen Stand, der auch bei VDR 2.2 schon Standard sein sollte. Damit ist das Paketieren eleganter.


    Im Prinzip könnte man den auch ganz weglassen und das PKGBUILD entsprechend umfummeln. Aber wegen "never change a running system" habe ich ihn doch dringelassen.


    Nachtrag:

    Bug #2543 Build errors with GCC 7.2.1

    Feature #2542 Upgrade the Makefile to the new VDR plugin Makefile standard

  • seahawk1986 Kannst du mir erklären warum du beim Type-Casting zwischen "unsigned" und "signed" variierst? Wäre nicht "unsigned" generell OK?

    Ist das nicht Implementationsabhängig, ob ein char signed oder unsigned ist (http://www.cplusplus.com/reference/climits/)? Aber du hast Recht, ein unsigned char sollte vom Wertebereich besser passen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Allgemeine Frage: Warum braucht man den Mist überhaupt? Der Compiler kann doch garnicht so doof sein nicht zu wissen, dass er das, was ich ins Array direkt zuweisen will, natürlich in dem Format ist, das das Array selbst hat. Wozu soll ich z.B. bei einem Array dem ich 100 Elemente zuweise jetzt 100 mal eine Zahl nach char casten?

    Da ein char nicht den Wertebereich eines int abdeckt, könnte es bei einer Umwandlung dazu kommen, dass der Wert verfälscht wird. Implizite Umwandlungen sind nur dann unproblematisch, wenn garantiert ist, dass der Wertebereich vom Zieltyp abgedeckt wird: http://en.cppreference.com/w/c…guage/implicit_conversion


    Bei einem char-Array kann man auch die chars escaped in einem String setzen, wenn man keine Umwandlung von int nach char will:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)