No worries :). The fact that you didn't see a proper configure error message suggests that the follow up patch to verify the qnx installation didn't make it or is buggy. Hmm.
Simon Original Message From: Rafael Roquetto Sent: Tuesday, March 8, 2016 19:48 To: Hausmann Simon Cc: development@qt-project.org Subject: Re: [Development] QNX broken on 5.7 Hi Simon, You are right, I completely forgot about that thread. Thanks for the feedback. Cheers, Rafael On Tue, Mar 08, 2016 at 06:31:15PM +0000, Hausmann Simon wrote: > Hi, > > When building Qt 5.7 for QNX a special patch is applied in the CI that fixes > the Dinkumware headers. You were CCed when this was discussed (Subject was > "QNX and Dinkumware support for constexpr and nullptr"). > > Simon > > Original Message > From: Rafael Roquetto > Sent: Tuesday, March 8, 2016 18:39 > To: development@qt-project.org > Subject: [Development] QNX broken on 5.7 > > > Hello everyone, > > I would like to point out that QNX is unable to build the 5.7 branch. The > commit that probably triggered the breakage is: > > d6bb01e1779f1840dfbab57c6ecd615587bbde62 > Force inclusion of <atomic> on QNX systems. > > > This raises my first question: should this not have been reported by the CI? > This is not the first time that changes go in and break QNX, in spite of > having the CI in place. Would anyone have a clue about what is going on? > > > Now, concerning the issue itself, it seems to be a bigger problem: > > /usr/include/cpp/xxatomic: In instantiation of > 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]': > /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void > (*)(QtMsgType, const char*)' to 'void*' [-fpermissive] > /usr/include/cpp/xxatomic:873:15: error: initializing argument 1 of > 'void* std::_Atomic_address::operator=(void*)' [-fpermissive] > > > Caused by the following line inside qlogging.cpp: > > static QBasicAtomicPointer<void (QtMsgType, const char*)> msgHandler = > Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); > > The problem can be traced to the Dinkumware's std::atomic implementation. > Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's > default ctor, which looks like this: > > _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT > { // construct from _Right > _Atomic_address::operator=(_Right); > } > > > _Atomic_address is a base class. As you can see, this ctor is implemented > using operator=, which looks like this: > > > inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT > { // assign _Value to *this > atomic_store(this, _Value); > return _Value; > } > ` > > where _TYPE expands to (void *), thus effectively causing the conversion from > void (*)(QtMsgType, const char*) to (void *), which is the error. > > Interestingly, Dinkumware's std::atomic does provide operator= in terms of > _Ty: > > > _Ty *operator=(_Ty *_Right) _NOEXCEPT > { // assign from _Right > return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right)); > } > > > which makes me think that the ctor is wrongly implemented, since it bypasses > this and calls the base class operator= explicitly. > > > I am not sure how to work around this. QBasicAtomicPointer won't let me > initialize it with some ugly (void *) pointer. > > Does it make sense to revert this patch? Is there a way to fall back to the > old non-C++11 implementation? > > Thanks, > Rafael > > -- > Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development