@EML100 said in 5.12.x offline installer fails on Centos 7: could not load xcb:
An offline Qt install from approved Centos rpms was an option, but I went for the stand-alone Qt install to avoid what would certainly have been a couple of days fixing rpm dependencies.
The Qt offline installer does not contain the 3rd-party dependencies. You still need to manually install the dependencies.
I imagine that fixing dependencies would be much easier if you installed Qt from an official CentOS RPM for your particular version of CentOS, instead of using the latest qt.io installer.
this is 7.3.1611, ie. RHEL 7.3 from Nov 2016
If you want to try the offline installer, you might have an easier time with Qt 5.9 LTS which is still supported for the next few months: http://download.qt.io/official_releases/qt/5.9/5.9.9/
But, I still think that using an official CentOS RPM is your best bet.
Note that Qt 5.12 supports and is tested on RHEL 7.4 as a minimum, so is not guaranteed to work out-of-the-box on RHEL 7.3:
https://doc.qt.io/qt-5.9/supported-platforms.html
https://doc.qt.io/qt-5.12/supported-platforms.html
The system probably initially had freetype 2.4.11-15 on it, and I replaced this with 2.8.14 rpm, which "fixed" the DBUS error when running as root, but not as myself.
FT_Get_Font_Format was introduced in FreeType 2.6: https://github.com/juj/emscripten-freetype/commit/f4d1c11faa116daad655b50828a434babbdaed2a
But anyway, your symptoms sound quite odd to me: Upgrading FreeType got rid of D-Bus error messages? And only for the root user but not normal users? I'm not sure how to begin diagnosing this; your machine might be in an inconsistent state.
The current problem is that something in this procedure has broken Subversion, which doesn't run at all now. I'm going to have to roll back on freetype at least, and try to find anything which the offline installer has changed.
Again, the Qt offline installer does not install any 3rd-party system-wide libraries. It only touched /opt/Qt5.14.0/ according to your original post.
As an aside, it would be interesting to find out how the devs managed to roll a binary release which they think is compatible with common distros. This appears to be next to impossible. When I do this (a lot) I do a release for the main distros, compiled for the first, or slightly after the first, minor release. My RHEL code is compiled on 7.1, for example.
I don't know the details, but you could try subscribing to the Interest mailing list and asking the devs directly.
I suspect they do so by building against the lowest supported versions of all dependencies (see https://doc.qt.io/qt-5.9/linux-requirements.html for example). They would try to stick to these versions for as long as possible until the benefits of upgrading outweigh the costs of supporting an old version.
