Issues building Qt5

[psmedley]

I am currently unable to build Qt5. A log of issues with the wiki instructions is below: 1st Issue - Build instructions at https://github.com/bitwiseworks/qt5-os2/wiki/Developers#building-qt Step 1 need to include gcc-g++, pthread-devel, gperf, bison, flex as well. 2nd issue - Reboot is required after step 2 to load config.sys parameters for GCC 3rd issue - 'SET MAKESHELL=dash.exe' needs to be set, otherwise make.exe tries to use cmd.exe

I'll continue to update this ticket as other issues are identified.

[dryeo]

Libevent seems to also be a requirement

[Greggk]

The nasm that is built as part of the web engine build process fails while if you instal the nasm rpm it works. Step one needs to include nasm as well. gpref and nss-devel are needed as well

The build stuff that needs python 2 is configured using the file name python2.exe while the version shipped is named python2.7.exe

The instructions say use make -jN all however this overrides the -nomake examples -nomake tests directives.

CDPATH must not be defined in the environment or it may interfere with some of the relative paths in the makefiles.

%Temp% must point to a drive with a lot of free space. Mine was on a ram disk the was only 500 MB, We know the amount needed is greater than a GB

There is no config.h generated for OS2 for libxsl. The linux one needs to be hacked to get it to work. U:\QT5_Workspace\qt5\qtwebengine\src\3rdparty\chromium\third_party\libxslt\linux\config.h A simular issue exests for libxml. Perhaps it wasn't intended for these to be built (ie just use the one from the rpms). In that case flag to prevent them from building should be set somewhere.

[dryeo]

If you look at config.summary in the root of the object directory, under Optional system libraries used, here there is,

libxml2 and libxslt .................. yes

Here the build died due to missing minizip, looks like it looks for lcms2 as well.

[dryeo]

Here with anything besides make -j1, such as mke -j3 results in lockups. Not surprising with the memory usage. CC1PLUS or something seems to be multi-threaded as using -j1 I still see 2-3 cores at 100% Need to have a swap file too. With 4GB of ram, my swap grew to 440 MB's before I got a sys0147 in make. This left a zombie process and stable system but needing a reboot to continue. Besides VIRTUALADDRESSLIMIT=3072, need to consider other ways to have memory available, less threads (perhaps 512 instead 1024) for example.

[StevenLevine]

I've not seem this kind of swap file growth here, but you might be further along in the build process.

I think if you check, you will find that the compiler is single threaded. Easy to check with Theseus. There might a server thread and worker thread, but I don't recall seeing anything like this in the gcc sources I happen to have browsed. However, a given gcc invocation can create several processes that might be passing data via a pipe. This might explain why you find multiple cores active.

In some cases the build system creates huge source files in the build tree. This speeds up the build, but uses more memory. It would be good if we could control this, but I've not yet found any build option that might allow us to limit the size of these created files.

Available, but unused threads use very little memory.

[dryeo]

Seems I only have 3.2 GB of ram accessible to the system, which might be the reason for the swap file growth. Didn't watch last night but today after the build finished, it is sitting at 50 MB. Doing a rebuild, the extra cores didn't get busy until building the webengine, so mis-interpretation on my part, appears Ninja tries to use all cores. The huge source files might be a good thing, when Mozilla started doing that, the memory requirements dropped enough that it stopped being a problem to be careful of. Around FF10, with 1.5 GB of ram, the swap file actually overflowed here, swap full crash at 2GB or so. The rebuild, after I added the last prerequisites and deleted the configure cache, status etc but not the tree took about 12 hours. What we really need is ccache ported to cache the object file so a change doesn't mean a full rebuild.

[dmik]

Regarding build requirements. The best place for requirements is actually https://github.com/bitwiseworks/rpm-specs/blob/master/qt5-qtbase/qt5-qtbase.spec (and other Qt5 specs). It's always 100% accurate because this is how we build our official RPMs.

Regarding multi-threadness. GCC is (IIRC) single-threaded. It's make that starts multiple GCC processes in parallel dramatically increasing memory consumption. IIRC, here the WebEngine build only survives in -j2 mode (i.e. two GCC processes). It's much slower but at least it can eventually finish the build.

PS. Yes, I just checked WebEngine spec, I force -j2 there indeed: https://github.com/bitwiseworks/rpm-specs/blob/26325b3a2a3d36d57b34cb9a3e325c84e356b7bf/qt5-qtwebengine/qt5-qtwebengine.spec#L470

[StevenLevine]

You do realize that this repo is some sort of private?

[dmik]

Well you are right, but nevertheless, it can always be extracted from a respective SRPM file. We might also come up with a better solution for the repos.

[StevenLevine]

If it were me, the .spec files would be kept in the corresponding source repo. It's not like they ever needed to be private.

You told me at one time why it was decided to keep the .spec files private, but can't recall what they were.

[dmik]

Having .spec files in a corresponding source repo is generally a bad idea maintenance wise because they are logically decoupled. Those .spec is merely building and packaging details for a specific package manager / OS combination while sources are agnostic in this regard. And releasing a package may happen completely independently of updating the sources.

Anyway, the rpm-specs repo is now public.

[StevenLevine]

While what you say is true in theory, our spec files, like numerous files in a given source repo, are platform (aka OS/2) specific and contain changes specific our port of the package manager.

IAC, as long as they are in a publically visible repo, that's good enough for me.