Building Qt as static libraries and linking on RedHat 7.2
-
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...
-
@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.
-
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.
-
@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. -
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.
-
@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 fromlibQt5Core.so.5.0.0
tolibQt5Core.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.
-
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.
-
@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.
-
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.
-
@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.
-
I have no choice the company I'm contracting to required a licensed version of Linux.
-
@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.
-
Thats ok, no offence taken :)