pkg/55283: Qt5 doesn't compile on sparc, seems to be a QtMutex problem

[romain%dolbeau.org@localhost]

>Number:         55283
>Category:       pkg
>Synopsis:       Qt5 doesn't compile on sparc, seems to be a QtMutex problem
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 21 15:40:00 +0000 2020
>Originator:     Romain Dolbeau
>Release:        2020Q1 (also checked with 2107Q1)
>Organization:
>Environment:
NetBSD ss20.dolbeau.name 9.0 NetBSD 9.0 (GENERIC.MP) #0: Fri Feb 14 00:06:28 UTC 2020  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/sparc/compile/GENERIC.MP sparc (true hardware)

and

NetBSD vmsparc.dolbeau.name 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/sparc/compile/GENERIC sparc (qemu)

>Description:
Qt5 (specifically, qt5-qtbase in /usr/pkgsrc/x11) doesn't compile on sparc. Primary symptom is an apparent hang while generating files using 'uic', but it happens later with other qt-based commands (e.g. qdbusxml2cpp).

I originally discovered the problem with 2020Q1 (v 5.14.2) but also went back to 2017Q1 (v 5.5.1) in the hope it was a recent bug - but it isn't, v5.5.1 has the same issue (in fact some of the findings below are from v5.5.1).

It seems the issue lies with mutex/lock, and in particular recursive QtMutex. The neverending programs do a lot of atomic operations (__atomic_compare_exchange_4 in particular) when examined in GDB, with a backtrace going through QtMutex functions. I tried on real hardware (SS20 with dual SM61) to make sure it wasn't a Qemu artifact, same thing.

After poking around in the 'qdbusxml2cpp' case, I realized some mutex ended up in QBasicMutex::lockInternal, despite the fact they looked a lot like recursive mutexes. This can be confirmed by enabling asserts in the src/corelib/thread/qmutex.cpp, by e.g. adding:

#ifdef QT_NO_DEBUG
#warning "QT_NO_DEBUG enabled, disabling"
#undef QT_NO_DEBUG
#endif

at the beginning of the file. This causes the offending binaries to crash with a segmentation fault in a string function (!!), whose backtrace goes through the failed assert "Q_ASSERT(!isRecursive())". I tried added '-O0' to the compiler command line, didn't help.

Unfortunately, I have no idea how to fix this. It could be a bug in QtMutex, it could also be a bug in the toolchain as such things are probably quite sensitive to the behavior of atomic operations and pre-v9 sparc isn't very good on that front :-(

Anyway I figure I should document my findings here just in case...
>How-To-Repeat:
Try to build qt5-qtbase on NetBSD 9.0/sparc. It never ends, as some program (uic in src/widgets probably will be first) never finishes.
>Fix:
None, sorry.