Re: Fedora mass rebuild 2017

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux