On 15/02/17 11:30 +0000, Jonathan Wakely wrote:
>On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
>>On 7 February 2017 at 16:32, Marek Polacek wrote:
>>>libffado-2.3.0-1.fc26.src.rpm
>>>sflphone-1.4.1-20.fc26.src.rpm
>>> error: no matching function for call to ...
>>> Invalid code.
>>
>>I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
>>new compiler attempting to compile (or verify) code in template
>>classes even if they are not initialized?
>
>Yes, exactly. Previously GCC was fairly forgiving about broken
>template code and would check almost nothing until the template was
>instantiated. In more recent releases parts of the template which
>don't depend on the template arguments get checked earlier. Clang has
>been doing this for some time, but it's a more recent change for GCC.
>
>>I suspect that there is
>>broken code in the Threading class.
>
>The standard says such code is ill-formed, but that no diagnostic is
>required i.e. the compiler is allowed to diagnose the problem, but not
>required to (because it could be expensive or difficult to check for
>some compilers). So the code was always broken, but now GCC tells you
>about it.
>
>
>
>>
>>log:
>>-----
>>usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
>>function for call to '_init_threading(DBus::Mutex* (&)(), void
>>(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
>>DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
>>(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
>>DBus::Mutex*, int), void (&)(DBus::CondVar*), void
>>(&)(DBus::CondVar*))'
>> );
>> ^
>>/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
>>void DBus::_init_threading()
>>void DXXAPI _init_threading();
>> ^~~~~~~~~~~~~~~
>>/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
>>candidate expects 0 arguments, 10 provided
>>/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
>>void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
>>DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
>>DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
>>DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) <near match>
>>void DXXAPI _init_threading(
>> ^~~~~~~~~~~~~~~
>>/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
>>conversion of argument 3 would be ill-formed:
>>-----
>>
>>see:
>>http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html
>
>The types MutexLockFn and MutexFreeFn depend on a macro:
>
>#ifndef DBUS_HAS_RECURSIVE_MUTEX
>typedef bool (*MutexFreeFn)(Mutex *mx);
>typedef bool (*MutexLockFn)(Mutex *mx);
>#else
>typedef void (*MutexFreeFn)(Mutex *mx);
>typedef void (*MutexLockFn)(Mutex *mx);
>#endif//DBUS_HAS_RECURSIVE_MUTEX
>
>But the type of the functions passed to _init_threading is always the
>same:
>
> static void mutex_free(Mutex *mx)
> {
> delete mx;
> }
>
> static void mutex_lock(Mutex *mx)
> {
> mx->lock();
> }
>
>That certainly looks suspicious.
More than suspicious. The DBus API docs at
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html
seem to say that the MutexFreeFn should always return void (for the
recursive and non-recursive versions) but it depends on
DBUS_HAS_RECURSIVE_MUTEX here. MutexUnlockFn should depend on
DBUS_HAS_RECURSIVE_MUTEX, but is always the same type here.
Worse, the functions in the C++ API return bool, but the functions in
the C API return dbus_bool_t which is a typedef for dbus_uint32_t, so
the types don't match and calling them is undefined.
It looks like dbus-c++ is abandoned though, the upstream repo was at
gitorious.org which is gone.
Nothing in dbus-c++ or libffado or sflphone uses the broken code in
dbus-c++ so it looks like it can just be commented out. See the
attached patch, which I'm testing now.