Building Qt as static libraries and linking on RedHat 7.2

[Simon Platten]

I have a system running RedHat 7.2, we have a commercial license for Qt and are getting ready to deploy and application, however we would like to statically link the application with the Qt library and other shared object libraries to make deployment easier.

I found several online tutorials and posted yesterday on how to build a static library, however:

1. I can't find that post.
2. Although I managed to build a static library, I then built it and linked the application, ran it and it crashed immediately.

I'm now trying to rebuild Qt on another system and am struggling with building the static Qt libraries. Can anyone point me to a reliable and tested source that I can follow?

We are using Qt 5.6

Thank you,

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

we would like to statically link the application with the Qt library and other shared object libraries to make deployment easier.

As usual, my advice is: don't do it, use shared objects.

I then built it and linked the application, ran it and it crashed immediately.

How do you mean? What crashed? What's the error?

Can anyone point me to a reliable and tested source that I can follow?

This one looks about right.

[Simon Platten]

Thank you, I retraced my steps and this is the link I was originally using and am now using again:

http://doc.qt.io/qt-5/linux-deployment.html

The reason for static over dynamic is to simplify the role out, we are using Qt for development and as far as I am aware they're isn't a package and deployment tool that would help greatly and if it existed would mean we could use the shared object libraries.

[Edit] The build of the static libraries has finished however, I don't see libQt5SerialPort.a which I need...

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

as far as I am aware they're isn't a package and deployment tool that would help greatly and if it existed would mean we could use the shared object libraries.

It exists - the Qt Maintenance Tool. It allows you to select what binaries to install (compiler compatibility/Qt version) and where. If it's for development only, I usually use my own build from git. Static lib is really, really bad idea for development, the linker step can take forever. Also you can build Qt (or rather the QtBase module) dynamically and build anything that depends on it statically, with the assumption the modules you need are relatively small (as is with QtSerialPort).

The build of the static libraries has finished however, I don't see libQt5SerialPort.a which I need

Did you do an install? Usually it'd be in <QT_SOURCE_DIR>/src/qtserialport/lib if you didn't install.

Kind regards.

[Simon Platten]

Thank you I am rebuilding the library now. The static build is intended purely for deployment and release not development.

I though the maintenance tool was for system recovery, didn't realise it was for deployment.

[Edit] I just ran the Maintenance tool and it is as I thought a recovery and removal tool. There is nothing in it to help deployment and packaging.

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

I though the maintenance tool was for system recovery, didn't realise it was for deployment

It is not. It's for development. For deployment, there's the specific Qt tool for windows and osx, for linux you'd usually not deploy Qt along (at least I don't).
EDIT: I've misread your post, sorry for the confusion about the Qt Maintenance tool.

[Simon Platten]

No problem, what I would like is a packager that identifies what libraries are required, grabs them and packages then into an installer that we can use for installations and be assured that nothing is missing.

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

No problem, what I would like is a packager that identifies what libraries are required, grabs them and packages then into an installer that we can use for installations and be assured that nothing is missing.

That's the thing, you shouldn't ... it's sounds counterintuitive I know, but Linux distros have their own repository and in that repository there's Qt, to which you should stick. Qt is binary compatible just for that reason, the API is allowed to (breakingly) change only between major versions, which means that things developed with Qt 5.0 should work out of the box if you just substitute the target of the libQt5Core.so symbolic link from libQt5Core.so.5.0.0 to libQt5Core.so.5.7.0. You can deploy Qt binaries as well, but it starts to get really painful if there's a change in one of the underlying libraries the Qt platform integration plugins depend on. Same problem with static builds, you can't build the kernel API statically, right, plus you get one big monster executable and you need to initialize the plugins Qt uses manually from code (which Qt does automagically when the loader loads the corresponding .so). Just my 2 cents.

If you still decide to walk the "deploy Qt binaries" way then the Qt documentation provides a relatively comprehensive text, as you've already found out, on how to do it.

[Simon Platten]

Now I'm confused, what are you saying...I have built at least 4 RedHat 7.2 systems and none of these had the Qt shared object libraries after the install. This is why we are looking at static builds.

I've just relinked our application with the static libraries and I get:

This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Reinstalling the application may fix this problem.
Aborted (core dumped)

[Edit] I've run ldd on the application and noted the referneced libraries, I added all these to the project but it still comes up with the same error.

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

none of these had the Qt shared object libraries after the install.

Have you installed Qt from the distribution's repository? I work on Debian (testing), here's what I have for Qt, all precompiled and ready to be installed.

This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

As I said, with static linkage the plugins must be loaded from code.

Look here and here for more info. It should be enough to add:

CONFIG += static

for your application, so I'd start there.

Kind regards.

[Simon Platten]

Thank you, will look into this....

hmm...I found one post from last year:

https://blog.qt.io/blog/2015/06/24/qt-is-coming-to-red-hat-enterprise-linux/

However there isn't any recent activity on this and I'm not sure that Qt5.6 libraries are available from any repositories.

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

However there isn't any recent activity on this and I'm not sure that Qt5.6 libraries are available from any repositories.

I can't say, sorry. You may be right that there isn't a prebuilt binary, I never cared much for the RedHat family, so I'm not up to date.

[Simon Platten]

I have no choice the company I'm contracting to required a licensed version of Linux.

[kshegunov]

@Simon-Platten said in Building Qt as static libraries and linking on RedHat 7.2:

I have no choice the company I'm contracting to required a licensed version of Linux.

I didn't mean to imply that you should switch, I only meant that I am not up to date with RedHat and what it provides.

[Simon Platten]

Thats ok, no offence taken :)

[SGaist]

Hi,

Just in case, there's a WIP tool available here which goal is to be integrated in Qt in the long run.

Hope it helps

[kshegunov]

@SGaist
This is so new and fresh, I love it. I'll consider making a few pull requests in the near future. :)