Building and shipping QT 6.10 on RHEL 8

Dan D

Hi, I was working on a project with QT 6.11 dependencies.

That project needs RHEL 8 as minimum supported version. QT 6.11 prebuilt binaries are not available on RHEL 8. But the QT support matrix mentions RHEL 8 with gcc-toolset-10 as supported.

Do I need to build QT (along with WebEngine - need that as well) on RHEL 8 and then ship those binaries along with my application?

Is it safe and stable to do so? What risks I am signing up for if I build Qt and web engine on RHEL 8 and build/ship deb and rpm packages from RHEL 8 for all other Linux distros?

What are the best practices and general recommendations for such cases?

Also, QT mentions gcc-toolset-10 but project uses C++23 features, so I need to build with gcc-toolset-13 as minimum. Would that create issues?

Note: I use LGPL license not commercial.

Apologies if I am asking basic questions. I am new to this kind of stuff.
Thank you! Looking forward for your suggestions.

SGaist

Hi and welcome to devnet,

There's not problem using a more recent compiler.
Qt requires a minimal C++ standard, and it's C++17 currently if memory serves well, but that does not forbid you to use a more recent standard.

As for building and shipping Qt along your application, you will need to have a starter script that ensures your application folder is searched first for their dependencies.
You might also want to consider building Qt using a custom namespace so as no to clash with the system provided Qt.

Dan D

Thanks for the clarification.

A few follow-up questions:

If I build and bundle Qt 6.11 + QtWebEngine myself on RHEL 8, what is the usual process for tracking bug-fix and security updates? Do teams typically monitor Qt releases and manually rebuild/retest for each 6.11.x update?
Are there any special considerations for building QtWebEngine (build time, hardware requirements, common issues on RHEL 8)?
My plan is to bundle Qt libraries with the application and use RPATH/RUNPATH instead of relying on system Qt packages. Is this considered a recommended deployment approach?
Regarding gcc-toolset-13 and C++23: if both Qt and the application are built with GCC 13, is the main requirement simply thorough testing on the target distributions, or are there additional compatibility concerns I should be aware of? GPU stacks are a concern?

Thanks!

SGaist

If you want to build things yourself, then yes, you should monitor your dependencies.
Long, lots of RAM and disk space due to chromium, I have no specific knowledge for that part. QtWebEngine is a module that I avoid building as much as possible.
Yes it's a good way, I am recommending the launcher script changing LD_LIBRARY_PATH and starting your application to add another level of certainty to the search paths. However, don't touch the user environment.
if you are testing on all your official targets, it should be good. As for GPUs, are you going to make anything specific for them ?

jeremy_k

@SGaist said in Building and shipping QT 6.10 on RHEL 8:

Yes it's a good way, I am recommending the script and LD_LIBRARY_PATH to add another level of certainty to the search paths.

I'd caution against setting or expecting LD_LIBRARY_PATH in a user's environment. The same applies to any commonly used environment variable. That risks impacting programs started by child processes in unfortunate ways.
For a real world example, PyInstaller sets LD_LIBRARY_PATH to force loading of bundled libraries. In my application, that prevented launching a web browser to view html documentation due to an incompatible bundled library.

SGaist

@jeremy_k I agree, the user environment shall be left untouched. I meant doing that through a launcher script for your application.

I fixed the wording.

jeremy_k

@SGaist Thanks for the clarification. LD_LIBRARY_PATH and other dynamic linker features are great development tools.