Hi Thiago, Thanks for the details, i'll switch to qt-interest. I've made progress but still have a weird package conflict for QtWebEngine.
Chris On 7 January 2018 at 03:27, Thiago Macieira <[email protected]> wrote: > 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 > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
