Mxe-octave: "qfloat16.h:300:7: error: ‘numeric_limits’ is not a class template"

On of my Linux boxes I installed Fedora 34. Next I successfully built, installed and run & used Octave-7.0.0 and then I tried to crossbuild it.
Somewhere halfway, the crossbuild breaks in qtbase with:

g++ -c -o qutfcodec.o …
… qfloat16.h:300:7: error: ‘numeric_limits’ is not a class template

This doesn’t look like an octave bug per se (as building Octave is still way off when mxe-octave is just at qtbase). But as it is in mxe-octave where the build breaks on an otherwise unmodified source file package downloaded straight from the web, I thought to first ask here:
Anyone with a clue how to figure out how to search for the cause, or even how to fix it?

As an aside, mxe-octave doesn’t check (in the very beginning, under “checking requirements”) for openssl (required to check the downloaded package checksums; it took me a while to figure out why all downloads were rejected) and openssl-devel (required for building cmake). I’m a bit surprised that such basic SW wasn’t installed by Fedora, but anyway it may be wise to include this in the mxe-octave checks.

In fact both qendian.h AND qfloat16.h are using std::numeric_limits and both are missing the include.

qendian.h uses std::numeric_limits but does not #include <limits>. As a result, any QT application using QtEndian fails to build with gcc11 (e.g. Fedora Rawhide) with a ton of errors like:

In file included from /usr/include/qt5/QtCore/qendian.h:44,
from /usr/include/qt5/QtCore/QtEndian:1,
from yet_another_qt_bug.cpp:2:
/usr/include/qt5/QtCore/qfloat16.h:300:7: error: 'numeric_limits' is not a class template
300 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public numeric_limits<float>

Aha, thanks for the quick reply.

And yes I copied only one of the errors, there were several more, also one about:
“… qfloat16.h:300:77: error: expected ‘{’ before ‘<’ token”

Perusing that bug report I see that “The real cause is that Qt is missing the includes” which makes me wonder why it does work on about any other distro. Do I guess rightly that the missing includes are provided by the compilers on those other distros?

The key is probably the gcc version not sure how many other distros are using gcc 11 yet.

@PhilipN: How did you configure MXE Octave?
By default, it builds its own gcc cross-compilers that should still be compatible with Qt5.15.2.

Edit: Noticed too late that the snippet you are showing calls “g++” (not a cross compiler). Maybe that’s while building a native tool.
Maybe this:
Fix build with GCC 11: include (8252ef5f) · Commits · Qt Project / qt / qtbase · GitLab (

Yep - QT build a number of native tools as part of the build (moc, uic, qmake, lrelease)

@PhilipN: Could you try dropping the patch in this .7z file into the src folder:
qtbase-2-kde-fixes.7z (374.7 KB)

I created it with git format-patch origin/5.15.2..origin/kde/5.15 --output=qtbase-2-kde-fixes.patch in a local copy of this repository:
Qt Project / qt / qtbase · GitLab (

Does it compile correctly with that patch?

Thanks for this Markus, sure I’ll try tonight. I thought about setting up this patch myself but you beat me to it.
Do I need to uncompress the patch (guess so)?

Yes, please decompress the patch. I would have uploaded the uncompressed file. But it was too large for the forum.

Afaict, MXE Octave doesn’t decompress patches by itself.

Sorry. That patch doesn’t apply.
I thought I could follow this:
Qt5PatchCollection - KDE Community Wiki
But it looks like the tarball is newer than the 5.15.2 repository.

Are you sure the patch is the proper one? 4.3MB is quite big for adding just an #include line to two include files. I also don’t see those two mentioned below.

I tried nevertheless but no joy:
(BTW sorry for sage font sizes, Discourse has its way of displaying text copied into place that I cannot master)

>     [build]    qtbase
> Failed to build package qtbase!
> ------------------------------------------------------------
> patching file src/platformsupport/themes/genericunix/dbusmenu
> /qdbusmenuconnection_p.h
> patching file src/testlib/qabstractitemmodeltester.cpp
> patching file tests/auto/testlib/qabstractitemmodeltester
> /tst_qabstractitemmodeltester.cpp
> patching file src/testlib/qabstractitemmodeltester.cpp
> patching file tests/auto/testlib/qabstractitemmodeltester
> /tst_qabstractitemmodeltester.cpp
> patching file src/corelib/thread/qmutex.cpp
> patching file src/corelib/thread/qmutex.h
> patching file src/corelib/thread/qwaitcondition_unix.cpp
> patching file src/testlib/qabstractitemmodeltester.cpp
> patching file tests/auto/testlib/qabstractitemmodeltester
> /tst_qabstractitemmodeltester.cpp
> patching file src/corelib/time/qtimezone.cpp
> patching file tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp
> patching file src/widgets/itemviews/qtreewidget.cpp
> patching file tests/auto/widgets/itemviews/qtreewidget
> /tst_qtreewidget.cpp
> patching file src/corelib/itemmodels
> /qconcatenatetablesproxymodel.cpp
> patching file tests/auto/corelib/itemmodels
> /qconcatenatetablesproxymodel
> /tst_qconcatenatetablesproxymodel.cpp
> patching file src/widgets/widgets/qcombobox.cpp
> patching file src/widgets/itemviews/qtableview.cpp
> patching file tests/auto/widgets/itemviews/qtableview
> /tst_qtableview.cpp
> patching file src/widgets/itemviews/qtableview.cpp
> patching file src/platformsupport/input/xkbcommon/qxkbcommon.cpp
> patching file src/dbus/qdbusmetaobject.cpp
> patching file src/corelib/global/qrandom.cpp
> patching file src/corelib/io/qfilesystemwatcher_inotify.cpp
> make[1]: *** [/home/philip/devel/octdev/mxe/mxe_w64b_20210501
> /Makefile:976: build-only-qtbase] Error 1
> make[1]: Leaving directory '/home/philip/devel/octdev
> /mxe/mxe_w64b_20210501'
> real    0m10.272s
> user    0m4.792s
> sys     0m1.571s
> ------------------------------------------------------------
> [log]      /home/philip/devel/octdev/mxe/mxe_w64b_20210501/log/qtbase
> make: *** [Makefile:979: /home/philip/devel/octdev
> /mxe/mxe_w64b_20210501/installed-packages/qtbase] Error 1

I also tried with a tiny patch of just qendian.h and qfloat16.h:

--- qtbase-everywhere-src-5.15.2/src/corelib/global/qendian.h	1970-01-01 01:00:00.000000000 +0100

+++ …/qtbase-everywhere-src-5.15.2/src/corelib/global/qendian.h 2021-05-03 19:31:42.272299710 +0200
@@ -44,6 +44,8 @@
#include <QtCore/qfloat16.h>
#include <QtCore/qglobal.h>

// include stdlib.h and hope that it defines GLIBC for glibc-based systems
#include <stdlib.h>
#include <string.h>
— qtbase-everywhere-src-5.15.2/src/corelib/global/qfloat16.h 1970-01-01 01:00:00.000000000 +0100
+++ …/qtbase-everywhere-src-5.15.2/src/corelib/global/qfloat16.h 2021-05-03 19:32:25.113488607 +0200
@@ -43,6 +43,7 @@

#include <QtCore/qglobal.h>
#include <QtCore/qmetatype.h>
#include <string.h>

#if defined(QT_COMPILER_SUPPORTS_F16C) && defined(AVX2) && !defined(F16C)

… but that also broke. with mention of improper syntax in include files.

I also get the impression that qtbase-1-fixes.patch doesn’t match, I see several mentions of
“Reversed (or previously applied) patch detected! Assume -R? [n]”

All in all I don’t trust my mxe-octave tree anymore. I keep a clone of the repo up-to-date and occasionally I copy it to a new mxe-octave tree where I bootstrap & configure & apply various local mods. That has been working fine on Mageia, but now in Fedora I’ll clone again and start over from scratch. Let’s see if that works better.

The patch doesn’t apply for me either. See above.
I tried to follow the instructions by the KDE guys. But clearly I’m missing something crucial…

Attached is Fedora’s patch to buils qtbase.qt5-qtbase-gcc11.patch (5.2 KB)

Thanks, but this patch woks better but still isn’t enough. From the mxe-octave build log:

g++ -c -pipe -O2 -std=c++11 -fno-exceptions -Wall -Wextra -ffunction-sections -fdata-sections -D_REENTRANT -fPIC -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_UIC -DQT_NO_CAST_FROM_ASCII -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_BOOTSTRAP_LIB -DQT_VERSION_STR='"5.15.2"' -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=15 -DQT_VERSION_PATCH=2 -DQT_BOOTSTRAPPED -DQT_NO_CAST_TO_ASCII -I. -I. -Ishared -Icpp -I. -Ipython -I../../../include -I../../../include/QtCore -I../../../include/QtCore/5.15.2 -I../../../include/QtCore/5.15.2/QtCore -I../../../include/QtXml -I../../../include/QtXml/5.15.2 -I../../../include/QtXml/5.15.2/QtXml -I../../../mkspecs/linux-g++ -o .obj/ui4.o ui4.cpp
WARNING: Failure to find: /home/philip/devel/octdev/mxe/mxe-octave/tmp-qtbase/qtbase-everywhere-src-5.15.2/src/corelib/qt5core_metatypes.json
In file included from ../../../include/QtCore/5.15.2/QtCore/private/qoffsetstringarray_p.h:1,
                 from ../../dbus/qdbuserror.cpp:44:
../../../include/QtCore/5.15.2/QtCore/private/../../../../../src/corelib/tools/qoffsetstringarray_p.h:70:22: error: ‘numeric_limits’ is not a member of ‘std’
   70 |         Last <= std::numeric_limits<quint8>::max(),
      |                      ^~~~~~~~~~~~~~
../../../include/QtCore/5.15.2/QtCore/private/../../../../../src/corelib/tools/qoffsetstringarray_p.h:70:43: error: wrong number of template arguments (1, should be 3)
   70 |         Last <= std::numeric_limits<quint8>::max(),
      |                                           ^
In file included from ../../../include/QtCore/../../src/corelib/global/qglobal.h:45,
                 from ../../../include/QtCore/qglobal.h:1,
                 from ../../../include/QtDBus/../../src/dbus/qtdbusglobal.h:43,
                 from ../../../include/QtDBus/qtdbusglobal.h:1,
                 from ../../dbus/qdbuserror.h:43,
                 from ../../dbus/qdbuserror.cpp:40:
/usr/include/c++/11/type_traits:92:12: note: provided for ‘template<bool <anonymous>, class, class> struct std::conditional’
   92 |     struct conditional;
      |            ^~~~~~~~~~~
In file included from ../../../include/QtCore/5.15.2/QtCore/private/qoffsetstringarray_p.h:1,
                 from ../../dbus/qdbuserror.cpp:44:
../../../include/QtCore/5.15.2/QtCore/private/../../../../../src/corelib/tools/qoffsetstringarray_p.h:70:44: error: expected identifier before ‘::’ token
   70 |         Last <= std::numeric_limits<quint8>::max(),
      |                                            ^~
../../../include/QtCore/5.15.2/QtCore/private/../../../../../src/corelib/tools/qoffsetstringarray_p.h: In instantiation of ‘constexpr QOffsetStringArray<T, SizeString, SizeOffsets>::QOffsetStringArray(const QtPrivate::StaticString<SizeString>&, QtPrivate::IndexesList<SizeString, Ox ...>) [with int ...Ox = {0, 8, 14, 48, 84, 126, 161, 199, 239, 281, 321, 357, 392, 429, 469, 509, 548, 589, 625, 669, 713, 754, 797, 841, 882, 924, 969, 1013, 1054}; T = QtPrivate::IndexesList<1055, 0, 8, 14, 48, 84, 126, 161, 199, 239, 281, 321, 357, 392, 429, 469, 509, 548, 589, 625, 669, 713, 754, 797, 841, 882, 924, 969, 1013, 1054>; int SizeString = 1055; int SizeOffsets = 29]’:
../../dbus/qdbuserror.cpp:86:1:   required from here

There are several other errors. Log attached.

All in all I think I better give up cross-compiling for Windows on Fedora for now. Maybe after the Fedora devs have sorted this out i’ll try again.
qtbase.log.7z (22.3 KB)

On a related note, the primary reason I tried Fedora (= broken zlib on Mageia, see bug #60450 comment #5) became moot as the Mageia folks have just patched zlib; I still have to try it in Mageia’s Cauldron dev build, once I have time.

There are 2 more patches that do not list gcc11, but do add

+#include <limits>

qtbase-QTBUG-89977.patch (514 Bytes) qtbase-QTBUG-90395.patch (1.1 KB)

Those are upstream patches.

I guess that is the costs of “living at the cutting edge”.
I don’t think there is anything the Fedora devs can do to resolve this particular issue. Instead, the package (in this case Qt5 base) needs to be fixed to be compatible with the newer compiler in Fedora. That probably needs to happen by the packager (i.e. MXE Octave) in this case.
There won’t be any more openly accessible updates for Qt5. So we can’t just update to a newer version. Instead, we’d need to fix the compatibility issues (and security, crashes and broken functionality issues) ourselves.

I’m using Ubuntu 20.10 currently which packages gcc 10. So I can’t reproduce the issue you are seeing here.
It’s difficult to predict which patches would be needed without studying all of the changes that were done in their repository since Qt5.15.2 was released. And like you have seen, that single patch wasn’t enough to be gcc 11 compatible.

IIUC, the KDE devs already do the effort of selecting, testing and backporting patches that fall into the above categories. My goal was to piggyback their effort and apply all the patches they deemed necessary at once.
Obviously, this needs to be done differently somehow.

Afaict, the tarball we are downloading in MXE Octave doesn’t match the 5.15.2 label in their git repository. I’m not sure why that is, or what needs to be done differently to get patches from the kde/5.15 branch in their repository that do apply correctly on the tarball we are using.

Yeah bleeding edge has its inconveniences :slight_smile:
At the same time I have issues with new SW running on older (not legacy) HW, for me that’s another motive to switch Linux distros. Ubuntu 20 is another candidate indeed (tried it already) but Fedora 34 was the best on that HW until now.

Anyway I’ll be running out of time rather than energy to try to fix all this yet, there’s room for just a few more things until much later this month.

Thank you all so far.

If you still find the opportunity to test: Could you please remove any prior patch from this thread and instead apply this patch to MXE Octave?
mxe-qtbase-5.15-kde.patch (971.5 KB)

It goes the opposite way. Instead of trying to upgrade the official release tarball, it will download a specific commit from KDE’s maintenance branch for Qt5.15.

Does that compile correctly for you with gcc 11?

Edit: I forgot that this would affect the other Qt packages too. Please use this patch instead:
mxe-qtbase-5.15-kde_v2.patch (975.1 KB)


Unfortunately it doesn’t work, kde’s setup is different than qtbase-everywhere*, patching fails. Log attached
qtbase (4.7 KB)
(I renamed the patch to qtbase-2-fixes.patch and put it in mxe-octave/src/, is that wrong? or I didn’t understand the proper procedure)

Sorry. I probably wasn’t clear enough. That patch is to be applied on MXE Octave. The patch will make changes to the build rules and will add a new file.