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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
