I am tying to update to Qt 6.6 (namely I need at least 6.5 for QQmlApplicationEngine::loadFromModule). I have tried:
- Using apt (it has 6.2 or 6.4 I believe)
- Pulling from Debian Enterprise
- I have a student account that they have confirmed can access it, however it doesn’t authenticate me, I expect because I actually don’t have access
- Using the Unified Qt Installer
- this doesn’t work cause it seems to require “ld-linux-x86-64.so.2” (as per readelf -d qt_installer.run)
So now I am building from source. However there seems to be significant architectural differences between what Qt supports (x86, opengl, etc.) and this use case (arm, weston/wayland, etc.). I have tried building from source, however it throws errors for linking against opengl. I currently have imx-gpu-viv-wayland-dev installed, which i know replaces some opengl libraries.
My questions:
- How to build? Is there anything I need to configure for this specific container image?
- If I am correct in configuration, what can I do to fix these errors?
- What do I even do to learn about the graphics architecture to get this done?
Hardware:
Apalis iMX8
Greetings @lucien950,
I see you’re trying to do something quite interesting here. For context let me explain how we package Qt in our containers. First we take the normal Debian repo for the Qt packages. For example qt6-base: debian · master · Debian Qt and KDE Team / Qt6 / qt6-base · GitLab
Then we fork this and make changes to the packaging and building of the package. This is to account for the differences in graphical architecture as you’ve already noticed. Since we’re forking off the original Debian repo this means we use whatever version they’re currently using, which in this case would be 6.4 I believe. Looking at the developer information here: qt6-base - Debian Package Tracker
I can see that the Debian guys have qt 6.6 in their experimental feeds. I’m unsure when this will make it’s way to the stable feeds though. With the context out of the way let me try and address your questions:
How to build? Is there anything I need to configure for this specific container image?
You could try and build the experimental feeds as I showed above, though this probably won’t be optimized for the graphics hardware/stack our modules use.
If I am correct in configuration, what can I do to fix these errors?
As said before you’ll probably need to do similar modifications as we have to build Qt for our grapics stack. These modifications are available in our fork, but this fork is internal at the moment and I’m unsure if I’m free to share this.
What do I even do to learn about the graphics architecture to get this done?
Well if you really want to learn you could reference the NXP documentation regarding their GPU and the graphics stack surrounding it.
With all that said, let me bring this up with some of my colleagues internally and see if they have any ideas.
Best Regards,
Jeremias
1 Like
I discussed this briefly internally. It would seem my initial points still stand. If you want to use Qt 6.6 you’ll need to rebuild it using the experimental feed Debian has. The experimental feed from Debian should become the next stable feed for the next stable version of Debian (Trixie).
Though it’s probably not enough to just rebuild Qt 6.6 you’ll also need to provide the dependencies for Qt 6.6. Which probably depend on newer versions of packages than the one available in the current stable version (Bookworm).
In short, it’s not impossible, but we can’t really guarantee how well any of this would work since it would involve integrating software that is currently marked as experimental in Debian. That said this probably is not a very trivial task.
If you could get this Debian Enterprise process you mentioned earlier to work, this could be a way forward without having to deal with the packages yourself. Though I don’t know if the packages provided from Qt this way would be optimized for the Apalis i.MX8 GPU and have proper hardware acceleration.
Best Regards,
Jeremias
Hi,
is their a timeline, when the qt6 docker container from Toradex will be updated?
The debian master seems to be updated to QT 6.8.3 already.
Best
Nils
Hello @nilsnxp,
We follow the stable version of qt6-base. So currently we are on 6.4.2. We plan to upgrade to 6.8.2 which will be the next enterprise version from Qt. I don’t have a timeline for this yet. If I find a rough timeline, I will update it here for you.
