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

[Christian Gagneraud]

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 <thiago.macieira at intel.com> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development