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

[Thiago Macieira]

On Thursday, 4 January 2018 20:52:40 -02 Christian Gagneraud wrote:
> On 5 January 2018 at 03:16, Kevin Kofler <kevin.kofler at chello.at> wrote:
> > Thiago Macieira wrote:
> >> In particular: -no-sse2.
> >> 
> >> If you use that option, that means you're optimising for Pentium III and
> >> earlier, not Pentium 4. All Pentium 4 processors have SSE2.
> 
> I was looking at LEDE (a fork/merge of OpenWRT) recently, and their
> 'i386' build actually target Pentium 4, which is i686++
> See https://lede-project.org/docs/instructionset/i386_pentium4

I don't know what devices LEDE is targetting, but we can break down 32-bit x86 
into four segments:

1) IA MCUs (Intel Quark™ line): these are 32-bit-only MMU-less systems, with 
RAM measured in kilobytes. This is not relevant for Qt or, for that matter, 
Linux. If you're interested, my colleagues support it with the Zephyr Project.

2) Atom line: these are modern, low-power devices meant for embedded use, The 
initial run was 32-bit, but all modern Atom are 64-bit and support SSE 4.2. 
That's also what the Android x86-64 ABI requires.

3) regular desktop, laptop and server processors: we can assume they are 64-
bit, since that's over 10 years old now. The first 64-bit Intel Macs also had 
SSE 4.2 support and that was 2009. Cloud infra usually runs on top of Intel 
Xeons, the first version of which was based on the Nehalem or Westmere 
architecture (also SSE 4.2). I'm not that familiar with AMD offerings, but 
looking at GCC's source code shows all modern AMD products also have AVX or 
AVX2. Our minimum Windows version (7) had quite good 64-bit support too. 
Finally, the only feature that glibc's ld.so uses to search for different 
libraries in 64-bit is AVX2 (2013). 

4) obsolete processors: anything that is over 10 years old. Still a target for 
Linux distributions.

Obviously, my employer would like nothing better than we start targetting 2 
and 3. Those billions of transistors you have in your processor for AVX should 
get used to improve performance, not just produce heat.

> I have been fighting with x86_32 build of Qt too, I never managed to
> build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly
> the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a
> docker container.

I've never had a problem, but I confess I don't try to build all of Qt. I 
build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The 32-bit 
build is only for qtbase, once every couple of months. For example, I still 
need to do the benchmarking for the new qHash function in 32-bit, which I find 
to be a poor use of my time so I haven't done yet.

[*] not including qtwebengine. I've never built that.

> You're not (and I'm not either) the first one to report problems with
> building Qt on x86_32 Linux recently.
> Linux32 is officially not supported any more, and I think it is a mistake.

Yes, it is. Please report issues so we can fix them.

> Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong.

Agreed. There are people who need it. Very few, but they exist.

It's only a matter of priorities. See the listing above: 32-bit processors 
only either fall into the "out of scope" category (microcontrollers) or 
"obsolete". So please don't expect us to dedicate a lot of time to it.

Supply patches.

> And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6
> (LTS) was not a user/client friendly move either.

Since it wasn't dropped, the point is moot.

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