In summary, I’m trying to build an OpenGL application inside a docker container, and running into package management issues.
I’m able to successfully start from torizon/debian:3-bullseye and install most of the development packages (taking care to select specifically qt5base-gles-dev and any other gles variants.
However, the issue occurs with the webkit -dev package. It insists on needing qt5base-dev as a dependency which then force-removes the -gles packages and will result in a non-working application due to linking “normal” OpenGL libraries. (e.g. missing QOpenGLTimeMonitor symbol, which is indicative of this problem as it isn’t available in GLES )
Did I perhaps miss a pre-built container somewhere which already has the full complement of Qt development tools installed for targeting GLES?
Could you share exactly what the sequence of installs you are doing in the container so I can try and reproduce?
I know in the past we’ve had to fiddle with the dependency chains of apt in our containers to get around conflicts and issues before. In which case this may be another similar case.
This is the dockerfile I’ve assembled so far. I did see the cppQML template, but unfortunately it targets Qt6 - I did try Qt6 as well, but that resulted in other issues - it builds okay but then encounters issues both because it still seems to be targeting regular OpenGL, and if I work around that by forcing EGLFS instead of wayland, I get blank white screens or crashes in some areas because (I believe) QtWebKit has been deprecated and the software needs it.
A word of caution if you try to build this container as ARM on a desktop with torizon/binfmt - my computer did NOT like it and a few minutes into the compile it would completely lock up - black screen, no response, etc and the only solution was a hard reset with the power button. It takes a few hours to compile on the 8MP itself, and you’ll definitely need a heatsink/fan or it’ll take even longer…
I did also see some of the shenanigans in the toradex qt5-wayland containers regarding one of the packages and had a slight go at something similar (large commented block here) but wasn’t successful at the initial attempt. I believe the status of this dockerfile is it will fail to build about halfway through because the Qt opengl development package is missing and QT += opengl in a makefile fails. If the stock one is installed (which removes the gles variants as previously noted) then it will finish building but produce a missing OpenGLTimeMon symbol error when attempting to run either the built mythtv-setup or mythfrontend application. I apologize if there are packages missing in the final container, I did not get past the initial missing symbol error to find if there were any additional ones missing.
Note there is code in place for this situation here - which is indicative the Qt development configuration is indeed not correct and it’s not targeting GLES properly.
There’s nothing proprietary here, I’m trying this out as a personal project to both become more familiar with a bare-bones approach to constructing a container application for Torizon, as well as fiddling with MythTV software on a SoC for a small form-factor HTPC. (It’s been reported to run satisfactorily on a Raspberry Pi which is also GLES only, so I don’t think the iMX8 should have any issues here - just a matter of getting the build dependencies right.)
Much like wayland, it requires access to /dev/input, dri, and galcore. to run Note that the hwcursor option in kms.conf causes flickering and graphics glitches which is why it’s omitted. It’s fine for this application as it’s meant to be key-driven input anyway (IR remote, or CEC for example).
FROM torizon/debian:3-bookworm as build
# The below FROM doesn't work because imx-gpu-viv-wayland conflicts with libegl, libgl libdrm, etc as pulled in by their corresponding -devel packages.
#FROM torizon/qt5-wayland-vivante:3 as build
RUN apt-get -y update && \
apt-get -t testing install -y --no-install-recommends binutils xz-utils qtbase5-gles-dev libegl-dev libgles-dev && \
apt-get -t testing install -y --no-install-recommends build-essential ccache default-libmysqlclient-dev git libasound2-dev libass-dev libavahi-compat-libdnssd-dev libavc1394-dev libbluray-bdj libbluray-dev libcdio-dev libcdio-paranoia-dev libcec-dev libdate-manip-perl libdatetime-format-iso8601-perl libdbd-mysql-perl libdbi-perl libdrm-dev libegl1-mesa-dev libexiv2-dev libfftw3-dev libflac++-dev libflac-dev libfreetype6-dev libgnutls28-dev libiec61883-dev libimage-size-perl libio-socket-inet6-perl libjson-perl liblzo2-dev libminizip-dev libmp3lame-dev libnet-upnp-perl libpulse-dev libqt5core5a libqt5gui5-gles libqt5sql5-mysql libsamplerate0-dev libsoap-lite-perl libsoundtouch-dev libssl-dev libsystemd-dev libtag1-dev libtool-bin libva-dev libvorbis-dev libvpx-dev libwww-perl libx264-dev libx265-dev libxinerama-dev libxml2-dev libxml-simple-perl libxml-xpath-perl libxnvctrl-dev libxrandr-dev libxv-dev libxvidcore-dev libxxf86vm-dev libzip-dev nasm pkg-config python3-future python3-lxml python3-mysqldb python3-oauthlib python3-pycurl python3-requests python3-requests-cache python3-setuptools python3-simplejson qt5-qmake qtscript5-dev uuid-dev liblirc-dev
# RUN WORK_DIR=$(mktemp -d) \
# && apt-get install --no-install-recommends libqt5quick5-gles libqt5quickparticles5-gles \
# && apt-mark hold libqt5quick5-gles libqt5quickparticles5-gles \
# && cd $WORK_DIR \
# && apt-get download libqt5opengl5-dev \
# && ar x libqt5opengl5-dev_*_arm64.deb \
# && tar -xJf control.tar.xz \
# && ls -lh \
# && sed -i '/^Depends:/s/, libqt5gui5 (>= 5.1.0)//' control \
# && tar -cJf control.tar.xz control md5sums \
# && ar rcs libqt5opengl5-dev.deb debian-binary control.tar.xz data.tar.xz \
# && apt-get -y install --no-install-recommends ./libqt5opengl5-dev.deb \
# && cd ~ \
# && rm -rf $WORK_DIR \
# && apt-mark hold libqt5opengl5-dev \
# && WORK_DIR=$(mktemp -d) \
# && cd $WORK_DIR \
# && apt-get download libqt5webkit5-dev \
# && ar x libqt5webkit5-dev_*_arm64.deb \
# && tar -xJf control.tar.xz \
# && sed -i '/^Depends:/s/, qt5base-dev//' control \
# && tar -cJf control.tar.xz control md5sums \
# && ar rcs libqt5webkit5-dev.deb debian-binary control.tar.xz data.tar.xz \
# && apt-get -y install --no-install-recommends ./libqt5webkit5-dev.deb \
# && cd ~ \
# && rm -rf $WORK_DIR \
# && apt-mark hold libqt5webkit5-dev \
# && apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/* && mkdir /src && mkdir /mythtv
WORKDIR /src
RUN git clone https://github.com/MythTV/mythtv.git mythtv -b fixes/33 --depth 1
WORKDIR /src/mythtv/mythtv
# RUN ./configure --help && false
RUN ./configure --prefix=/mythtv --enable-opengles --disable-vdpau --disable-hdhomerun --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libxvid --disable-opengl
RUN make -j $(nproc)
RUN make install -j $(nproc)
WORKDIR /src/mythtv/mythplugins
#RUN ./configure --prefix=/mythtv
#RUN make -j $(nproc)
#RUN make install $(nproc)
FROM torizon/qt5-wayland-vivante:3 as final
COPY --from=build /mythtv /usr
RUN useradd --system mythtv && usermod -aG mythtv torizon
RUN apt-get -y update && \
apt-get -t testing install -y --no-install-recommends libtag1v5 libexiv2-27 python3-future python3-requests python3-requests-cache libavahi-compat-libdnssd1 libqt5script5 libqt5sql5-mysql pciutils libva-x11-2 libva-glx2 libdbi-perl libdbd-mysql-perl libnet-upnp-perl python3-lxml python3-mysqldb libcec6 libfftw3-double3 libfftw3-single3 libass9 libfftw3-bin libraw1394-11 libiec61883-0 libavc1394-0 fonts-liberation libva-drm2 libmp3lame0 libxv1 libpulse0 libhdhomerun4 libxnvctrl0 libsamplerate0 libbluray2 liblzo2-2 libio-socket-inet6-perl libxml-simple-perl libzip4 python3-lxml python3-mysqldb libsoundtouch1 libasound2 && \
apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/*
RUN echo '{"device": "/dev/dri/card0" }' > /etc/kms.conf
ENV LD_LIBRARY_PATH=/mythtv/lib
ENV QT_QPA_PLATFORM=eglfs
ENV PATH=$PATH:/mythtv/bin
Okay I did some tests here on my side. Let me try and simplify your scenario here to see if I understood everything.
Basically you have some code that requires qtbase5-gles-dev. If you install qtbase5-gles-dev on it’s own then it installs successfully, but then this package comes from the normal Debian feeds and is not built to utilize the GPU on the hardware.
If you install imx-gpu-viv-wayland first then install qtbase5-gles-dev, this results in failure due to:
The following information may help to resolve the situation:
The following packages have unmet dependencies:
qtbase5-gles-dev : Depends: libegl-dev
Depends: libgles-dev
Finally if you install qtbase5-gles-dev, then imx-gpu-viv-wayland this results in the initial package being removed like so:
Removing qtbase5-gles-dev:arm64 (5.15.8+dfsg-3) ...
Removing libgles-dev:arm64 (1.6.0-1) ...
Removing libegl-dev:arm64 (1.6.0-1) ...
Removing libgl-dev:arm64 (1.6.0-1) ...
Removing libgl1:arm64 (1.6.0-1) ...
Removing libgles1:arm64 (1.6.0-1) ...
dpkg: libgles2:arm64: dependency problems, but removing anyway as you requested:
libqt5gui5-gles:arm64 depends on libgles2.
Removing libgles2:arm64 (1.6.0-1) ...
dpkg: libegl-mesa0:arm64: dependency problems, but removing anyway as you requested:
libegl1:arm64 depends on libegl-mesa0.
Removing libegl-mesa0:arm64 (22.3.6-1+deb12u1) ...
dpkg: libgbm1:arm64: dependency problems, but removing anyway as you requested:
libqt5gui5-gles:arm64 depends on libgbm1 (>= 8.1~0).
Removing libgbm1:arm64 (22.3.6-1+deb12u1) ...
dpkg: libegl1:arm64: dependency problems, but removing anyway as you requested:
libqt5gui5-gles:arm64 depends on libegl1.
Removing libegl1:arm64 (1.6.0-1) ...
In summary you can’t find a way to both install the Qt5 GLES package you need along with the GPU libraries to make use of the GPU. Did I more or less understand everything right?
Yes - that is one set of problems if trying to build directly in the qt5-wayland-vivante container.
The other set is that if I try to build in the torizon/debian:3-bookworm container instead of the GPU container (with an intent to copy to the GPU container when the build is done) then attempting to install any of the following packages will result in the -gles Qt packages being purged in favour of the non-gles packages:
First of all let’s talk about the issue with qtbase5-gles-dev and imx-gpu-viv-wayland. We actually provide a dev version of this package imx-gpu-viv-wayland-dev. If you use this package it gets around the issue of unmet dependencies. Another thing is that this package provides it’s own equivalent variant of libgles-dev and such. This is why if you install this package after qtbase5-gles-dev you’ll notice some packages getting removed, it’s not exactly they get removed but rather replaced since imx-gpu-viv-wayland-dev can provide the same functionality.
It actually conflicts with qtbase5-gles-dev. This is probably why you see the gles Qt packages being purged in this case due to this explicit conflict in the Debian packaging definition.
With the information you gave me I was able to work around this by messing with the package dependencies (to not depend on qt5-base) for qt5webkit-dev and qt5opengl5-dev in the same way that qt5-wayland-vivante does with the base libqt5opengl5.
I’m pleased to report it did build successfully and now renders/runs as expected.
Just to follow up here with some additional info for the curious - My initial success was while working on the base container and installing the full complement of Qt development packages and the standard libGL/libEGL development libraries.
I have since modified the container to try doing it “right” using imx-gpu-viv-wayland-dev, and while this satisfies the project configuration, at link time it throws a number of errors for a few undefined glX* symbols, both via the code directly and via dependency libva2-glx This seems to suggest compiling against the gpu driver package’s implementation requires an additional library to be linked somewhere. These symbols must be present in the headers and libraries somewhere as otherwise it would have manifested earlier in the compile process or when attempting to run the application built in the initial configuration (without imx-gpu-viv-wayland-dev)
Of course. It’s a personal experiment project so I understand the implications; obviously that’d be a different story if this was going into any sort of official production
