Static Qt5 in Linux builds #6267

I see the Linux builds for 0.11.0rc1 are statically linked to Qt5, where previously they were dynamically linked to Qt4. I'm glad for the upgrade, not so much the static linking. Is there a reason for this, and could it be referenced in the release notes? My argument against would be, unlike OpenSSL, it's not consensus critical, and it's more important to be consistent with the distribution for look and feel. I realize this would reduce support for older distro versions. Alternately, could the static build be updated to the latest Qt (5.4 instead of 5.2)?

Specific issues I'm seeing, under KDE 5 / Fedora 22:

• Doesn't look like the system theme
• Systray icon missing (KDE 5 dropped support for the old xembed systray in favor of the appindicator/status-notifier protocol; handled transparently in Qt 5.4 and distro-patched 4.8)

I've compiled successfully against Qt 5.4.1, but can't actually test as Red Hat's lawyers are still hobbling secp256k1 in their OpenSSL package. Happy to test if an upstream build is done.

Because it's the most compatible option. I was against statically linking Qt first as well (because of the desktop integration problems), see discussion in #4284, but was eventually convinced because all the other options are even worse.

Gist of the matter is, that there is no good way to distribute portable GUI executables on Linux. Blame the weird ecosystem. Also now that libstdc++ is linked statically (another compatibility compromise, #5819) there is no other option than to link all c++ libraries as static.

Upgrading the static Qt version is fine with me, if that helps anything. Should be straightforward - see depends/packages/qt.mk.

I see. Well, at least it's no worse than the situation for Qt app deployment on Win/Mac.

Bumping the version in the recipe looks easy enough... testing on all the platforms, not so much. Should I just do it and let someone else find the breakage?

It may be more involved for that for osx/win, since Qt tends to mess with their cross-build configs pretty often. The good news, though, is that qt tends to become easier for us to build with each qt bump. You're welcome to give it a shot, maybe this will be a smooth bump :)

Otherwise, this is on my TODO shortlist for 0.12.

Work in progress at https://github.com/welshjf/bitcoin/tree/qt54. @theuni, do you know the reason for the sed -i.old "/XIproto.h/d" qtbase/src/plugins/platforms/xcb/qxcbxsettings.cpp? It's breaking the build due to missing LSBFirst/MSBFirst from X.h.

I've got everything to build but bitcoin-qt aborts with This application failed to start because it could not find or load the Qt platform plugin "xcb". So far I've traced it down to the configure check for x11-xcb not being run at all.

A few levels deeper:

The Q_IMPORT_PLUGIN directives aren't being enabled (from build-aux/m4/bitcoin_qt.m4) because the _BITCOIN_QT_IS_STATIC check is failing.

That's because the test program that checks for QT_STATIC always fails, because <QtCore> dies on including <QtCore/QtCoreDepends>, because the top level <basedir>/depends/<host>/include is not in the CFLAGS -- just the Qt* subdirs.

That's because Qt's pkg-config file generator no longer emits it, thinking it's the system include dir, at least under some circumstances. The change is https://codereview.qt-project.org/#/c/83469/ or commit 50b25458, first included in v5.3.1.

Still investigating whether there's a deeper reason why the Qt build thinks it's the system dir, or if we need some kind of hack to add it back in.

The Qt build system infers the default include path by parsing the output of g++ -v (qtbase/configure, line 3326, "Auto-detect default include and library search paths"). This is affected by the CPATH and QMAKE_CFLAGS settings in depends/packages/qt.mk. Simply deleting those works to get the top level include path back into the .pc files, but breaks the static OpenSSL linkage. What does work is to add the identical CPATH to the bitcoin build environment.

Tragically, after all that, the system theme and systray problems are still there. It would seem that the change in Qt 5.4 was not to automatically support the new systray, but rather just some refactoring that enabled KDE to hook into it via the system theme engine -- which only works with the shared Qt.

I'll still PR my work on the version bump, but not for 0.11 -- no point holding up the schedule if it doesn't solve the problem.

Yes, separately of that it'll still be nice to have a more recent Qt in 0.12, thanks for the work.

My update is working on Linux, but the mingw cross build is failing with undefined reference to symbol errors. (Qt itself builds but not bitcoin-qt.) I've found these difficult to track down, generally having to do with missing static libs or linking them in the wrong order -- the official solution is "just use qmake," I'm sure. I think I'll leave this one for someone more experienced ;) Would you like me to PR anyway, or just leave the work in my own branch?

I'd say PR it anyway. I'm sure someone can help get it to work for windows.

OK great. One more thing I want to fix is to only download the submodules we actually use (at least qtbase and qttranslations). The monolithic tarball grew from 224M in 5.2 to 398M in 5.4, and to make things worse their default mirror seems really slow.

Would also love to see Qt bump to 5.4.2 in 0.12. I'm ready to help testing and fixing (osx, window, linux and gitian-building).

I'm already running a Qt 5.4.2 bitcoin-qt.exe on Win8.1 without any problems currently (own toolchain).

I've also been running 5.4.x on OS X for a while now.

Closing this, as the original problems I cited are not likely to be fixed, and the Qt bump now has a PR.

Confirming this issue in Debian GNU/Linux Jessie (amd64, Xfce) after upgrading to 0.11.0. Fonts look absolutely horrible and I had to kill the process manually from an xterm when the GUI disappeared entirely (since I always use the minimise to system tray option).

I don't see any point in distributing GNU/Linux builds in this broken state. I'd suggest pulling it until 0.12 is out, replacing it with a source tarball for everyone to build themselves (which is what I ended up having to do), or putting a big red warning on the download link indicating that its known to be broken for many (most?) people.