NetBSD Problem Report #55283

From  Thu May 21 15:38:50 2020
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id 8E9551A9227
	for <>; Thu, 21 May 2020 15:38:50 +0000 (UTC)
Message-Id: <>
Date: Thu, 21 May 2020 15:38:49 +0000 (UTC)
Subject: Qt5 doesn't compile on sparc, seems to be a QtMutex problem
X-Send-Pr-Version: www-1.0

>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)
NetBSD 9.0 NetBSD 9.0 (GENERIC.MP) #0: Fri Feb 14 00:06:28 UTC 2020 sparc (true hardware)


NetBSD 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020 sparc (qemu)

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

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...
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.
None, sorry.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.