vdr-2.4.6 kompiliert mit gcc-11.0.0 nicht

kls · May 6, 2021 at 11:07 AM

Quote from kfb77

Auch das habe ich schon mal in einem Plugin gesehen: vdr-plugin-live

Wobei da

Code

hours = string(std::max(0,(int)(2 - hours.size())), '0') + hours;
mins = string(std::max(0,(int)(2 - mins.size())), '0') + mins;

gemacht wird, sollte also doch eigentlich kein Problem sein.

Ich würde jetzt mal vorschlagen, die Änderung von #12 zu machen (eventuell vielleicht sogar auch noch ohne DISABLE_TEMPLATES_COLLIDING_WITH_STL) und zu schauen, bei welchen Plugins Probleme auftreten. Dort sollte man dann schauen, ob sich das nicht einfach durch Voranstellen von "std::" lösen lässt. Wäre nett, wenn das jemand mal probieren könnte und hier Bescheid gibt.

Quote from wirbel

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

Das kann durchaus sein. Hat aber jahrelang funktioniert. Ich gebe natürlich zu, dass das keine "saubere" Lösung war ;-).

Quote from M-Reimer

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

kfb77 · May 6, 2021 at 1:07 PM

Die Plugins, die ich nutze (epg2vdr, epgsearch, live, markad, satip) bauen unter Ubuntu 20.04 ohne Probleme.

kls · May 6, 2021 at 1:32 PM

kfb77 Danke. Kannst du bitte noch schauen, ob in den Sourcen dieser Plugins irgendwo DISABLE_TEMPLATES_COLLIDING_WITH_STL vorkommt?

kfb77 · May 6, 2021 at 1:41 PM

Nein, nicht drin, nur im vdr Source gefunden.

wolfi.m · May 6, 2021 at 3:32 PM

Hi,

vdr-plugin-vnsiserver-1.8.0/streamer.c:34:#define DISABLE_TEMPLATES_COLLIDING_WITH_STL 1

Code

// work-around for VDR's tools.h
#if VDRVERSNUM < 20400
#define __STL_CONFIG_H 1
#else
#define DISABLE_TEMPLATES_COLLIDING_WITH_STL 1
#endif

Quote from kfb77

Die Plugins, die ich nutze (epg2vdr, epgsearch, live, markad, satip) bauen unter Ubuntu 20.04 ohne Probleme.

Ubuntu 20.04 bringt gcc-7 mit max. lässt sich gcc-10 installieren.

Es geht ja um gcc-11 ...Sorry,wenn ich was überlesen habe.

Bye

cu

kfb77 · May 6, 2021 at 3:35 PM

Es geht so wie ich das verstanden habe um beides: Geht nach der Änderung gcc-7 noch und auch gcc-11. Mein Beitrag bezog sich auf "gcc-7 noch".

kls · May 6, 2021 at 3:53 PM

Richtig, es sollte mit allen Compilern funktionieren, und möglichst ganz ohne #defines.

Falls also im Plugin entsprechende #defines vorkommen, diese bitte testweise auskommentieren.

M-Reimer · May 6, 2021 at 4:58 PM

Wäre es denn wirklich so schlimm das DEFINE als Option drin zu lassen?

Ja, über "using namespace std" scheiden sich die Geister aber zumindest ich hab das genau so im Studium vermittelt bekommen. Beim "normalen" C++-Programmieren braucht man die "std"-Dinger halt ständig und immer ein "std::" davor schreiben kann man machen, muss man aber nicht.

Ich bin und werde zwar nicht "hardcore Plugin-Entwickler", aber ich fände es trotzdem nicht verkehrt die Option, auch in einem Plugin "using namespace std" machen zu können, zu erhalten.

kls · May 6, 2021 at 5:01 PM

Das DISABLE_TEMPLATES_COLLIDING_WITH_STL kann meinetwegen ruhig bleiben. Ich möchte nur weg von den compilerspezifischen Abfragen, denn die können sich ja offensichtlich ändern.

wirbel · May 6, 2021 at 5:09 PM

Viele Wege führen nach Rom..

Selbst ein

namespace vdr {

#include <vdr/tools.h>

}

int n = vdr::max(..)

oder

{

using vdr::max;

int n = max(..)

}

M-Reimer · May 6, 2021 at 5:11 PM

Der war mir neu. Im Prinzip eine schöne Option, aber da kommt nicht jeder sofort drauf.

wirbel · May 6, 2021 at 5:16 PM

Also probiert/compiliert hab ich's jetzt nicht. Ich sag nur macros sind eher C-style als C++ ..

md_berlin · May 6, 2021 at 7:03 PM

Ich hab hier ein Problem mit epgsearch mit gcc-11 (gcc-9 und -10 compilen epgsearch ohne Probleme). Bei gcc-11 (vdr-1.4.7 ist gcc-11 übersetzt und installiert) gibt es eine Meldung, mit deren Kontext ich so gar nichts anfangen kann.

Es führt bereits das

conflictcheck.h:30 #include <set>
zu einem Abbruch.

Code

In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/set:60,
                from conflictcheck.h:30,
                from conflictcheck.c:26:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_tree.h: In instantiation of ‘static const _Key& std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_S_key(std::_Rb_tr
ee<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Const_Link_type) [with _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheckTimerObj*>;
_Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Const_Link_type = const std::_Rb_tree_node<cConflictCh
eckTimerObj*>*]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_tree.h:2069:47:   required from ‘std::pair<std::_Rb_tree_node_base*, std::_Rb_tree_node_base*> std::_Rb_tree<_Key, _Val, _Ke
yOfValue, _Compare, _Alloc>::_M_get_insert_unique_pos(const key_type&) [with _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheckTimer
Obj*>; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::key_type = cConflictCheckTimerObj*]’
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_tree.h:2122:4:   required from ‘std::pair<std::_Rb_tree_iterator<_Val>, bool> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compar
e, _Alloc>::_M_insert_unique(_Arg&&) [with _Arg = cConflictCheckTimerObj* const&; _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheck
TimerObj*>; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>]’
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_set.h:512:25:   required from ‘std::pair<typename std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename __gnu_cx
x::__alloc_traits<_Allocator>::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const value_type&) [with _Key = cConflictCheckTimerObj*; _Compare = Timer
ObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; typename std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::ot
her>::const_iterator = std::_Rb_tree<cConflictCheckTimerObj*, cConflictCheckTimerObj*, std::_Identity<cConflictCheckTimerObj*>, TimerObjSort, std::allocator<cConflictCheckTimerObj*> >::cons
t_iterator; typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::other = std::allocator<cConflictCheckTimerObj*>; typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key> = __g
nu_cxx::__alloc_traits<std::allocator<cConflictCheckTimerObj*>, cConflictCheckTimerObj*>::rebind<cConflictCheckTimerObj*>; typename _Allocator::value_type = cConflictCheckTimerObj*; std::se
t<_Key, _Compare, _Alloc>::value_type = cConflictCheckTimerObj*]’
conflictcheck.c:280:47:   required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_tree.h:770:15: error: static assertion failed: comparison object must be invocable as const
 770 |               is_invocable_v<const _Compare&, const _Key&, const _Key&>,
     |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_tree.h:770:15: note: ‘std::is_invocable_v<const TimerObjSort&, cConflictCheckTimerObj* const&, cConflictCheckTimerObj* const
&>’ evaluates to false

Display More

Ich hab schon mal probiert davor ein#define DISABLE_TEMPLATES_COLLIDING_WITH_STL zu setzen, ohne Veränderung.

Hat jemand eine Idee?

Source ist die neueste aus https://projects.vdr-developer.org/git/vdr-plugin-epgsearch.git/
Habe auch alle älteren Pakete durchprobiert, identischer Abbruch.

seahawk1986 · May 6, 2021 at 10:39 PM

Quote from md_berlin

Hat jemand eine Idee?

Ich würde mal zwei Dinge versuchen (ich habe noch keine Installation mit gcc-11):

in https://projects.vdr-developer.org/git/vdr-plugin…lictcheck.h#n73 ff. alles const machen:

Code

bool operator()(const cConflictCheckTimerObj* a, const cConflictCheckTimerObj* b) const {
        return (a->Compare(*b) < 0);
    }

wenn das nicht klappt in https://projects.vdr-developer.org/git/vdr-plugin…ee/Makefile#n86 ein -std=c++14 anhängen.

md_berlin · May 6, 2021 at 11:28 PM

Quote from seahawk1986
Ich würde mal zwei Dinge versuchen (ich habe noch keine Installation mit gcc-11):

in https://projects.vdr-developer.org/git/vdr-plugin…lictcheck.h#n73 ff. alles const machen:
Code
bool operator()(const cConflictCheckTimerObj* a, const cConflictCheckTimerObj* b) const {
        return (a->Compare(*b) < 0);
    }

Hi seahawk,

Sehr guter Hinweis, so lässt es sich compilen!!! Vielen Dank!

Nun muß es nur noch funktionieren, werde die nächsten Tage testen und dann "upstream" reporten.

Hier nochmal als Patch:

Diff

--- a/conflictcheck.h
+++ b/conflictcheck.h
@@ -73,7 +73,7 @@
class TimerObjSort
{
public:
-    bool operator()(cConflictCheckTimerObj* a, cConflictCheckTimerObj* b) {
+    bool operator()(const cConflictCheckTimerObj* a, const cConflictCheckTimerObj* b) const {
        return (a->Compare(*b) < 0);
    }
};

Display More

cocobrother · May 7, 2021 at 9:30 AM

kls

Das hab ich auch noch aber das kompilieren läuft durch. Version 2.5.3

util.c: In statischer Elementfunktion »static u_int32_t SI::CRC32::crc32(const char*, int, u_int32_t)«:

util.c:269:17: Warnung: ISO-C++17 erlaubt Speicherklassenangabe »register« nicht [-Wregister]

269 | register int i;

| ^

kls · May 7, 2021 at 11:01 AM

Lösch mal das 'register'.

cocobrother · May 7, 2021 at 2:44 PM

Quote from kls

Lösch mal das 'register'.

funktioniert….

wirbel · May 13, 2021 at 1:42 PM

Quote from kfb77

Auch das habe ich schon mal in einem Plugin gesehen: vdr-plugin-live

Hab dazu mal einen pull request bei MarkusE gestartet, dann ist es zumindest schon mal ein Plugin weniger.

M-Reimer · May 17, 2021 at 7:22 PM

Quote from wirbel

Viele Wege führen nach Rom..

Selbst ein

namespace vdr {

#include <vdr/tools.h>

}

int n = vdr::max(..)

oder

{

using vdr::max;

int n = max(..)

}

Display More

Ich hab jetzt doch mal recherchiert weil mir die Idee gefallen hat VDR-Header selbst in einen Namespace zu zwingen und:

Geht nicht https://stackoverflow.com/questions/5175…al-library-in-c

vdr-2.4.6 kompiliert mit gcc-11.0.0 nicht

Participate now!

Tags

Users Viewing This Thread