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

[Thiago Macieira]

On Thursday, 4 January 2018 23:40:40 -02 Christian Gagneraud wrote:
> It's not just about what hardware you target, in my case, i cannot
> build the codebase in 64 bits, simply because the code is not 64-bits
> ready (mainly due to legacy old/complicated components): Not only the
> code base is full of 32 vs 64 issues, but it actually doesn't build at
> all, and fixing it is not an easy job and not a priority (yet).

And that's an understandable, if unfortunate, situation. You should keep that 
version working, even if it means keeping an old compiler you know works, 
until you can clean up. But don't upgrade Qt either: keep the old version that 
you know was working.

You should also prepare disclaimers to your customers about security issues 
not being fixed.

> I wish too, i could target Linux-x86_64, but i cannot. This codebase
> currently builds for WINTEL32 and Linux/ARM32, it used to be built for
> a Geode or VIA proc, some time ago, with Qt-4.x

The fact that you mention Geode and VIA means it's *old*.

> And thinking about that, why is it a pain to maintain Linux-x86_32
> when you have to maintain Linux-<non-intel>_32 and <non-linux>-*_32?
> From http://doc.qt.io/qt-5/supported-platforms.html, Qt-5.10 supports
> the following 32 bits platforms:
> - Android-armv7
> - WatchOS-armv7
> - Windows-{7,8.1,10}-x86_32
> - Windows-UWP-{x86_32,armv7}
> - Boot2Qt-{armv7,x86_32}
> - Qnx-{armv7,x86_32}

It's not. Like I said, it is supported and there are no known issues with it. 
That is, if you use compilers and Linux distributions of equivalent age as the 
Qt that you're compiling.

A 10-year-old hacked compiler targetting a 10-year-old processor doesn't 
count.

> Please note the Boot2Qt-x86_32, which is a weird case as it is an
> "Embedded Linux" for x86_32 (Yocto).
> The only reason for supporting "Embedded Linux" for x86_32 and not
> "Desktop Linux" for x86_32 is, I guess, CI workload.

Also beats me. Like I said in my previous email, there were some 32-bit only 
Atoms in the beginning, but all new offerings in the last 4 years have been 
64-bit capable. There are considerable advantages in using 64-bit, and I would 
even need to see numbers to agree there's a code or data size increase.

I also know TQtC has been pushing hard for the Automotive segment and I know 
ALL of those are 64-bit capable (almost all are Intel).

> > 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.
> 
> Neatpick: AVX itself doesn't require billions of transistors, the
> first intel proc to require more than a billion transistor are 4 and 6
> cores i7.
> https://en.wikipedia.org/wiki/Transistor_count

Fair enough. The billions are usually due to expanded L3 caches, not the CPU 
itself. I was exaggerating.

Still, AVX and AVX2 are considerable die size (don't know how much).

> This slides are interesting as well,
> https://www.inf.ethz.ch/personal/markusp/teaching/263-2300-ETH-spring12/slid
> es/class03.pdf. L2/L3 cache is what takes the most space.

Some even have an "L4" shared with or even dedicated to the GPU, which is 
another transistor hog.

> > 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 told me so a few month ago, and I switched to OpenSuse since then,
> but i still had issues, and the only way to get around was to break
> the host distro (force-install some dev packages, 'ln -sf' SO here and
> there, ...)
> Please share your script if you have some.

Regular configure -platform linux-g++-32 && make. There's nothing special.

> > Yes, it is. Please report issues so we can fix them.
> 
> I might do it once i'm back on my 32 bits build task.
> But the difficulty is to create a "good" ticket. If I do it right now,
> the issue would look like:
> "I followed https://wiki.qt.io/Building_Qt_5_from_Git and i cannot
> build Qt-5.6 for x86_32 on a "common" Linux distro (x86_32/64)"

Your first few will probably be "you did something wrong", so post here so we 
can help you properly set up. You may be missing tools and development 
packages. Once we find an actual issue, someone will ask you to report (or 
just fix it).

> >> Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong.
> > 
> > Agreed. There are people who need it. Very few, but they exist.
> 
> What do you base your "very few" on?
> I would be interested to see the download stats of Qt-5.5 for Linux-32.

While I'd be interested too, you'll have to remember that's a 3 year old 
release, with 3 more years of people switching to 64-bit. Anyway, I base my 
answer on my listing from before, that ALL Linux-capable x86 CPUs sold in the 
last 4 years are 64-bit capable. The ones that weren't, from 2012 (early 
Atoms), are so slow and consume so much more power today that I don't expect 
them to be used for most serious purposes, and definitely not for any new 
project. 

Those few that do still use it for any reason can build from source.

> >> 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.
> 
> Linux-Desktop-x86_32 was dropped with Qt-5.6. The last Qt version to
> support it was Qt-5.5, and Qt-5.5 has now disappear from
> http://download.qt.io/official_releases/qt/ ...

You're mistaking support for creating binaries.

We do support a lot more than we create binaries for. We have to balance the 
interest in that download with the effort required to build, test and store 
forever the binary. For Qt 5.6, we judged that the effort outweighed the 
benefit of creating Linux 32-bit binaries.

> 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.

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