[Development] 32bit linux build of qt5.10.0 w/ webengine

[Thiago Macieira]

On Saturday, 6 January 2018 09:21:35 -02 Christian Gagneraud wrote:
> > Regular configure -platform linux-g++-32 && make. There's nothing special.
> 
> <ironic>Well, thanks for the tip!</ironic>

To be clear, this is my config.opt (newlines replaced by spaces). I have other 
options, but nothing special:

-opensource -confirm-license -developer-build -system-libjpeg -system-libpng 
-system-sqlite -reduce-relocations -xcb -pch -dbus-runtime -qtlibinfix .32 
-nomake tests -nomake examples -platform linux-g++-32-optimised
-qtnamespace QtI386 -release

As you can see, this is also my namespace-testing build. As for linux-g++-32-
optimised, it's basically adding -march=native -mno-rdrnd to QMAKE_CFLAGS.

> The main issue is dependencies, the best document I found is an ICS blog
> post: https://www.ics.com/blog/how-compile-qt-source-code-linux
> 
> But that covers only 32bits build on 32bits host or 64bits build on 64
> bits host.

$ rpm -qa --qf "%{NAME}\\n" *-devel-32bit
libstdc++-devel-32bit
libICE-devel-32bit
libxkbcommon-devel-32bit
libjpeg62-devel-32bit
xcb-util-wm-devel-32bit
libX11-devel-32bit
libSM-devel-32bit
libXext-devel-32bit
libxcb-devel-32bit
libpng16-devel-32bit
xcb-util-image-devel-32bit
dbus-1-devel-32bit
glibc-devel-32bit
xcb-util-keysyms-devel-32bit
libXi-devel-32bit

> When I asked my question a few month ago, it was all about how to
> install all the 32 bits (dev) packages on a 64 bits Linux machine
> without having to resort to "dirty hacks", and so far i've been
> unlucky, and nobody was able to give me any hints (not blaming anyone
> here)
>
> So may I rephrase my question?
> Do you have the magic list for apt/zypper that would allow to build
> Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine?

Try installing my listing above. It should be a good start.

It's probably not complete: you may need some more 32-bit tools that aren't 
*-devel-32bit and you need some 64-bit tools too.

> >> Or maybe we're not talking about the same thing. I'm not even sure
> >> what the Qt Company means by "Supported until Mar. 16, 2019" on
> >> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6).
> >> What I'm sure of, is that i cannot download Qt-5.6 binaries for
> >> Linux-x86_32 (commercial or opensource).
> > 
> > That's Qt 5.6's support lifetime. It's a Long Term Support release, so
> > we'll keep adding patches and fixes to it until that date. That includes
> > all compilers and platforms that were supported at the time of the
> > release, however difficult it may get for us next year to build.
> 
> Just a wee reminder that "support" doesn't mean "full support".
> Remember how we ended up on the gcc (or binutils?) bug board because
> the QThread test suite was failing?

Right, there are levels. There are platform combinations that are tested by 
the main CI; there are others that are tested only by the qt5.git CI. All of 
those are confirmed to be compiling and working at any release. Then there are 
those we are pretty confident on, but don't always check.

Here's the link for the last qt5 5.9 integration:
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1515209498

As you can see, there are a couple of 32-bit builds:
 * Android 32-bit x86
 * Integrity 32-bit ARM
 * Linux 32-bit ARM
 * QNX 32-bit ARM and x86
 * Windows 32-bit x86 (MinGW and MSVC)

So even though a 32-bit x86 build for regular Linux is missing, we should be 
pretty confident it works. It would only be failing if we had some x86-
specific Linux-specific (non-Android) code and I don't think we do. 

We have x86-specific code, but it's cross-OS and/or 64-bit capable too: the 
only thing I can think of that comes closest is the early CPUID detection, 
since all 64-bit CPUs have CPUID and the assembly is compiler dependent, but 
even then it's code we don't need to modify and it does get compiled on for 
both Android and MinGW.

> For me, it's quite simple:
> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt
> binaries = No (opensource/commercial) support.

No CI, see above.
No binaries, build from sources.
No support, sorry, I can't comment.

> If you don't build and test on a regular basis, it can break at any
> moment without anyone noticing (and it did happened at least once)

You're right, but given all the other permutations, we're very likely covered 
at a good 99% certainty.

> PS: In case you think I'm ranting for free here, i would like to say
> (again) that I think Qt is a great piece of (opensource/commercial)
> SW, and big thumb up to anyone behind this, The Qt Project, The Qt
> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or
> corporate.

We're having a constructive conversation, don't worry.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center