Menus from QMainWindow MenuBar not showing on Qt 6.4.0

jsulm

@davethomaspilot Yes, looks like you're using X11.
Could be that there is an issues with Qt6 and that OS version.

davethomaspilot

@jsulm Any suggestions on how to proceed?

ls there a way to tell if Qt 6.4.0 has been tested on Bookworm?
I configured to use OpenGL. Could that be a factor?
There is a link to install qt6 on bookworm simply, by installing qt6-base-dev. I haven't tried that. I don't know if it will replace the libraries I created with the cross-compile, or create a new set in a different folder. Should I pursue this route? It would be great to only have to cross-compile my Qt6 app, not Qt itself!

SGaist

Unless you installed your cross-compiled Qt in system folders (which you should not), installing the distribution packages should not interfere with them.

davethomaspilot

@SGaist Following this:

https://wiki.qt.io/Cross-Compile_Qt_6_for_Raspberry_Pi

It said to do this:

$ cd $HOME/rpi-sysroot
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/lib* rpi-sysroot/lib
$ mkdir usr
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/usr/include/* rpi-sysroot/usr/include
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/usr/lib/* rpi-sysroot/usr/lib
$ mkdir opt
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/opt/vc rpi-sysroot/opt/vc

which installs the libraries in /usr/lib. I think of those as "system folders". No?

Anway, that's where they are now.

Is there really a qt6 for rpi that can be installed simply rather than having to do the cross-compile?

SGaist

@davethomaspilot the instructions you show are to copy the dependencies from the RPi back to the host to create a sysroot for the cross-compilation process. The transfert of Qt to the RPi indicates to use /usr/local/qt6. So you should be good.

You can install Qt 6 using your RPi distribution packages.

Note that while the wiki shows 6.4.0, you should update Qt to 6.6. It might contain fixed for your issue.

davethomaspilot

@SGaist Thanks for the reply...

But, if there's an RPI distribution package, shouldn't I just use that?

I really don't even need Qt6 I just needed to update a hacked version of the pigpio library I did back in 2018 to work with RPI4. I figured I'd move up to the latest Debian and qt6 while I was at it, since the product will be used at least another 10 years (or until I can't get RPI4 anymore).

jsulm

@davethomaspilot said in Menus from QMainWindow MenuBar not showing on Qt 6.4.0:

But, if there's an RPI distribution package, shouldn't I just use that?

Yes. But if you do cross compilation you need to update the sysroot after Qt6 installation on RPi.

davethomaspilot

@jsulm Ok, I'll give it a try...

Things get confusing with cross-compilation, at least for me. Here's what I think I need to do. Sorry for the long post...

I'll install qt6 from the repos on the RPI. Then, when I do these commands:

$ cd $HOME/rpi-sysroot
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/lib* rpi-sysroot/lib
$ mkdir usr
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/usr/include/* rpi-sysroot/usr/include
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/usr/lib/* rpi-sysroot/usr/lib
$ mkdir opt
$ rsync -avzS --rsync-path="rsync" --delete <pi_username>@<pi_ip_address>:/opt/vc rpi-sysroot/opt/vc

A copy of the newly installed qt6 libraries will be copied to the build machine along with the other "system" libraries But, I will use a different sysroot folder, say repo-rpi-sysroot insted of rpi-sysroot-lib. Is this correct?

Then do the symlink thing (on the build machine) using this:

$ sudo apt install symlinks
$ cd ~
$ symlinks -rc repo-rpi-sysroot

I think I will need to rebuild my app (not QT6!) to link with the repo libraries. But, looking at myapplication's .pro file, I can't figure out how the sysroot libraries are being found:

#-------------------------------------------------
#
# Project created by QtCreator 2018-11-02T09:42:04
#
#-------------------------------------------------

QT       += core gui xml
QT       += serialport sql opengl

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets printsupport
greaterThan(QT_MAJOR_VERSION, 4): CONFIG += c++11
lessThan(QT_MAJOR_VERSION, 5): QMAKE_CXXFLAGS += -std=c++11
TARGET = LightTree
TEMPLATE = app

CONFIG += debug

#QMAKE_CXXFLAGS_RELEASE -= -O2
#QMAKE_CXXFLAGS_RELEASE += -Os


# The following define makes your compiler emit warnings if you use
# any feature of Qt which has been marked as deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS
//DEFINES += -Wno-switch

# You can also make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

#DEFINES += FIRST_PROTO
DEFINES += QCUSTOMPLOT_USE_OPENGL
SOURCES += \
        main.cpp \
        mainwindow.cpp \
    xemics.cpp \
    pigspi.cpp \
    xemicregs.cpp \
    pigpioread.cpp \
    timingevents.cpp \
    lightbar.cpp \
    treeevent.cpp \
    powercontrol.cpp \
    logger.cpp \
    ledbrightness.cpp \
    serial.cpp \
    readanalogparms.cpp \
    ledcontrol.cpp \
    bands.cpp \
    cadencecolors.cpp \
    stagedefs.cpp \
    demos.cpp \
    passsimulator.cpp \
    qcustomplot.cpp \
    leaderboard.cpp

HEADERS += \
        mainwindow.h \
    qcustomplot.h \
    xemics.h \
    pigspi.h \
    xemicregs.h \
    serial.h \
    pigpioread.h \
    timingevents.h \
    tree_events.h \
    ws2811.h \
    lightbar.h \
    treeevent.h \
    powercontrol.h \
    gpiodefs.h \
    logger.h \
    ledbrightness.h \
    readanalogparms.h \
    ledcontrol.h \
    bands.h \
    atmel_commands.h \
    cadencecolors.h \
    rpihw.h \
    pwm.h \
    stagedefs.h \
    demos.h \
    passsimulator.h \
    powercontrol.h \
    leaderboard.h


FORMS += \
        mainwindow.ui \
    xemicregs.ui \
    treeevent.ui \
    ledbrightness.ui \
    batteryvoltage.ui \
    bands.ui \
    cadencecolors.ui \
    demos.ui \
    passsimulator.ui \
    leaderboard.ui

ROOTFS = /home/davethomaspilot/rpi-sysroot
INCLUDEPATH += $${ROOTFS}/usr/include
#LIBS += -lwiringPi

DEFINES += SVN_REVISION=\\\"$$system("svn info --show-item revision")\\\"
DEFINES += BUILDDATE=\\\"$$system(date '+%m/%d/%y')\\\"
DEFINES += BUILDTIME=\\\"$$system(date '+%H:%M')\\\"

contains ( DEFINES, USE_PIGPIO_DAEMON ){
    LIBS += -lpigpiod_if2 -lrt
} else {
    LIBS += -lpigpio -lrt -lws2811
}
#-lsqlite
target.path = /home/pi/LightTree
INSTALLS += target

DISTFILES +=

RESOURCES += \
    myresource.qrc

unix:!macx: LIBS += -L$$PWD/../../../build-rpi_ws281x-LightTree-Debug/ -lws2811

INCLUDEPATH += $$PWD/../../../build-rpi_ws281x-LightTree-Debug
DEPENDPATH += $$PWD/../../../build-rpi_ws281x-LightTree-Debug

unix:!macx: PRE_TARGETDEPS += $$PWD/../../../build-rpi_ws281x-LightTree-Debug/libws2811.a

There is "ROOTFS", but it seems to only used for setting INCLUDEPATH. The -L flag doesn't use it--it just specifies the build directory:

unix:!macx: LIBS += -L$$PWD/../../../build-rpi_ws281x-LightTree-Debug/ -lws2811

Yet, I see from the compile output, the libraries from the sysroot are being found (/home/davethomaspilot/qt-raspi)

arch64-linux-gnu-g++ -c -pipe -pipe -march=armv8-a --sysroot=/home/davethomaspilot/rpi-sysroot -g -Wall -Wextra -D_REENTRANT -DQT_DEPRECATED_WARNINGS -DQCUSTOMPLOT_USE_OPENGL -DSVN_REVISION=\"1814\" -DBUILDDATE=\"11/05/23\" -DBUILDTIME=\"17:50\" -DQT_QML_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I../HJJ -I. -I../../../rpi-sysroot/usr/include -I../../../build-rpi_ws281x-LightTree-Debug -I../../../qt-raspi/include -I../../../qt-raspi/include/QtOpenGL -I../../../qt-raspi/include/QtPrintSupport -I../../../qt-raspi/include/QtWidgets -I../../../qt-raspi/include/QtGui -I../../../qt-raspi/include/QtXml -I../../../qt-raspi/include/QtSerialPort -I../../../qt-raspi/include/QtSql -I../../../qt-raspi/include/QtCore -I. -I. -I../../../qt-raspi/mkspecs/devices/linux-rasp-pi4-aarch64 -o logger.o ../HJJ/logger.cpp
aarch64-linux-gnu-g++ -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed --sysroot=/home/davethomaspilot/rpi-sysroot -Wl,-rpath,/usr/local/qt6/lib -Wl,-rpath-link,/home/davethomaspilot/rpi-sysroot/usr/lib/aarch64-linux-gnu -Wl,-rpath-link,/home/davethomaspilot/rpi-sysroot/lib/aarch64-linux-gnu -o LightTree  main.o mainwindow.o xemics.o pigspi.o xemicregs.o pigpioread.o timingevents.o lightbar.o treeevent.o powercontrol.o logger.o ledbrightness.o serial.o readanalogparms.o ledcontrol.o bands.o cadencecolors.o stagedefs.o demos.o passsimulator.o qcustomplot.o leaderboard.o qrc_myresource.o moc_mainwindow.o moc_qcustomplot.o moc_xemics.o moc_pigspi.o moc_xemicregs.o moc_serial.o moc_pigpioread.o moc_timingevents.o moc_lightbar.o moc_treeevent.o moc_powercontrol.o moc_logger.o moc_ledbrightness.o moc_readanalogparms.o moc_ledcontrol.o moc_bands.o moc_cadencecolors.o moc_demos.o moc_passsimulator.o moc_leaderboard.o   -lpigpio -lrt -L/home/davethomaspilot/StartLights/branches/HJJ/../../../build-rpi_ws281x-LightTree-Debug/ -lws2811 /home/davethomaspilot/qt-raspi/lib/libQt6OpenGL.so /home/davethomaspilot/qt-raspi/lib/libQt6PrintSupport.so /home/davethomaspilot/qt-raspi/lib/libQt6Widgets.so /home/davethomaspilot/qt-raspi/lib/libQt6Gui.so -lEGL /home/davethomaspilot/qt-raspi/lib/libQt6Xml.so /home/davethomaspilot/qt-raspi/lib/libQt6SerialPort.so /home/davethomaspilot/qt-raspi/lib/libQt6Sql.so /home/davethomaspilot/qt-raspi/lib/libQt6Core.so -lpthread -lGLESv2

I think they must be found using "cmake magic", from this:

-DCMAKE_TOOLCHAIN_FILE:UNINITIALIZED=/path/to/qt-raspi/lib/cmake/Qt6/qt.toolchain.cmake

But, that toolchain.cmake came from the QT6 build, I think?

I think I need to understand the mechanism that provided the fully qualified library "qt-raspi" names so the link on the build machine won't pick up the libraries from the QT build, but will instead link against those in repo-raspi-sysroot.

jsulm

@davethomaspilot said in Menus from QMainWindow MenuBar not showing on Qt 6.4.0:

But, I will use a different sysroot folder, say repo-rpi-sysroot insted of rpi-sysroot-lib.

Why? I mean, you can of course have as many sysroots as you like. But there is no need to create a new one just because of Qt.

davethomaspilot

@jsulm So as not to clobber the Qt libs I built. Compile time is measured in days.

davethomaspilot

@davethomaspilot I guess I don't really need new sysroot, but I DO need to link against the QT libraries that will have been copied from the RPI to the build machines sysroot. Versus those in qt-raspi (the ones I built from Qt 6.4 source).

davethomaspilot

@davethomaspilot The makefile for my app has the fully qualified QT library names in it:

LIBS          = $(SUBLIBS) -lpigpio -lrt -L/home/davethomaspilot/StartLights/branches/HJJ/../../../build-rpi_ws281x-LightTree-Debug/ -lws2811 /home/davethomaspilot/qt-raspi/lib/libQt6OpenGL.so /home/davethomaspilot/qt-raspi/lib/libQt6PrintSupport.so /home/davethomaspilot/qt-raspi/lib/libQt6Widgets.so /home/davethomaspilot/qt-raspi/lib/libQt6Gui.so -lEGL /home/davethomaspilot/qt-raspi/lib/libQt6Xml.so /home/davethomaspilot/qt-raspi/lib/libQt6SerialPort.so /home/davethomaspilot/qt-raspi/lib/libQt6Sql.so /home/davethomaspilot/qt-raspi/lib/libQt6Core.so -lpthread -lGLESv2   
AR            = aarch64-linux-gnu-ar cqs

I guess I can edit that file to link against the libs from the rpi repo install?

But, I don't understand how the file names got into the Makefile. There is nothing I can find in the .pro file that references anything in qt-raspi.

davethomaspilot

@davethomaspilot So, I remember from decades ago trying to manage multiple sets of libraries gets tricky... Another thing I don't understand---

When I do ldd on my application on the rpi, I get full qualified .so names frm /usr/local/qt6/lib. What's the mechanism that changed the .so file names from the /home/davethomaspilot/qt-raspi location to /usr/local/qt6/lib?

Or, maybe I give up on trying to understand "the magic".

What do I need to change on the build machine so my application links against the libraries from the RPI repo?

davethomaspilot

@davethomaspilot Apparently, ldd retuns fully qualified library names even when they are found using LD_LIBRARY_PATH.

So, I was able to install qt6 on the rpi from the repo, then set LD_LIBRARY_PATH to /usr/lib/aarch64-linux-gnu. I then see this:

pi@lighttree:~/LightTree $ ldd LightTree
	linux-vdso.so.1 (0x0000007f8ce2d000)
	libpigpio.so.1 => /lib/libpigpio.so.1 (0x0000007f8c9e0000)
	libQt6OpenGL.so.6 => /usr/lib/aarch64-linux-gnu/libQt6OpenGL.so.6 (0x0000007f8c920000)
	libQt6PrintSupport.so.6 => /usr/lib/aarch64-linux-gnu/libQt6PrintSupport.so.6 (0x0000007f8c880000)
	libQt6Widgets.so.6 => /usr/lib/aarch64-linux-gnu/libQt6Widgets.so.6 (0x0000007f8c150000)
	libQt6Gui.so.6 => /usr/lib/aarch64-linux-gnu/libQt6Gui.so.6 (0x0000007f8ba50000)
	libQt6Xml.so.6 => /usr/lib/aarch64-linux-gnu/libQt6Xml.so.6 (0x0000007f8ba00000)
	libQt6Sql.so.6 => /usr/lib/aarch64-linux-gnu/libQt6Sql.so.6 (0x0000007f8b990000)
	libQt6Core.so.6 => /usr/lib/aarch64-linux-gnu/libQt6Core.so.6 (0x0000007f8b4a0000)
	libGLESv2.so.2 => /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 (0x0000007f8b450000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007f8b230000)
	libm.so.6 => /usr/lib/aarch64-linux-gnu/libm.so.6 (0x0000007f8b190000)
	libgcc_s.so.1 => /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007f8b150000)
	libc.so.6 => /usr/lib/aarch64-linux-gnu/libc.so.6 (0x0000007f8afa0000)
	/lib/ld-linux-aarch64.so.1 (0x0000007f8cdf0000)
	libOpenGL.so.0 => /usr/lib/aarch64-linux-gnu/libOpenGL.so.0 (0x0000007f8af20000)
	libEGL.so.1 => /usr/lib/aarch64-linux-gnu/libEGL.so.1 (0x0000007f8aee0000)
	libfontconfig.so.1 => /usr/lib/aarch64-linux-gnu/libfontconfig.so.1 (0x0000007f8ae70000)
	libX11.so.6 => /usr/lib/aarch64-linux-gnu/libX11.so.6 (0x0000007f8ad10000)
	libglib-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000007f8abb0000)
	libQt6DBus.so.6 => /usr/lib/aarch64-linux-gnu/libQt6DBus.so.6 (0x0000007f8aae0000)
	libxkbcommon.so.0 => /usr/lib/aarch64-linux-gnu/libxkbcommon.so.0 (0x0000007f8aa70000)
	libGLX.so.0 => /usr/lib/aarch64-linux-gnu/libGLX.so.0 (0x0000007f8aa10000)
	libpng16.so.16 => /usr/lib/aarch64-linux-gnu/libpng16.so.16 (0x0000007f8a9b0000)
	libharfbuzz.so.0 => /usr/lib/aarch64-linux-gnu/libharfbuzz.so.0 (0x0000007f8a890000)
	libmd4c.so.0 => /usr/lib/aarch64-linux-gnu/libmd4c.so.0 (0x0000007f8a870000)
	libfreetype.so.6 => /usr/lib/aarch64-linux-gnu/libfreetype.so.6 (0x0000007f8a790000)
	libz.so.1 => /usr/lib/aarch64-linux-gnu/libz.so.1 (0x0000007f8a750000)
	libicui18n.so.72 => /usr/lib/aarch64-linux-gnu/libicui18n.so.72 (0x0000007f8a410000)
	libicuuc.so.72 => /usr/lib/aarch64-linux-gnu/libicuuc.so.72 (0x0000007f8a1f0000)
	libdouble-conversion.so.3 => /usr/lib/aarch64-linux-gnu/libdouble-conversion.so.3 (0x0000007f8a1b0000)
	libb2.so.1 => /usr/lib/aarch64-linux-gnu/libb2.so.1 (0x0000007f8a190000)
	libpcre2-16.so.0 => /usr/lib/aarch64-linux-gnu/libpcre2-16.so.0 (0x0000007f8a0f0000)
	libzstd.so.1 => /usr/lib/aarch64-linux-gnu/libzstd.so.1 (0x0000007f8a030000)
	libGLdispatch.so.0 => /usr/lib/aarch64-linux-gnu/libGLdispatch.so.0 (0x0000007f89ea0000)
	libexpat.so.1 => /usr/lib/aarch64-linux-gnu/libexpat.so.1 (0x0000007f89e50000)
	libxcb.so.1 => /usr/lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007f89e00000)
	libpcre2-8.so.0 => /usr/lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000007f89d50000)
	libdbus-1.so.3 => /usr/lib/aarch64-linux-gnu/libdbus-1.so.3 (0x0000007f89cd0000)
	libgraphite2.so.3 => /usr/lib/aarch64-linux-gnu/libgraphite2.so.3 (0x0000007f89c90000)
	libbrotlidec.so.1 => /usr/lib/aarch64-linux-gnu/libbrotlidec.so.1 (0x0000007f89c60000)
	libicudata.so.72 => /usr/lib/aarch64-linux-gnu/libicudata.so.72 (0x0000007f87e70000)
	libgomp.so.1 => /usr/lib/aarch64-linux-gnu/libgomp.so.1 (0x0000007f87e00000)
	libXau.so.6 => /usr/lib/aarch64-linux-gnu/libXau.so.6 (0x0000007f87de0000)
	libXdmcp.so.6 => /usr/lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007f87dc0000)
	libsystemd.so.0 => /usr/lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000007f87cd0000)
	libbrotlicommon.so.1 => /usr/lib/aarch64-linux-gnu/libbrotlicommon.so.1 (0x0000007f87c90000)
	libbsd.so.0 => /usr/lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007f87c50000)
	libcap.so.2 => /usr/lib/aarch64-linux-gnu/libcap.so.2 (0x0000007f87c20000
```)

Which is what I want to see!  But, I still have the same issue--menus from the QMainWindow menubar don't display.

So, if it's a problem with Qt6 on bookworm 64 bit, the problem is in the repo libraries too.

Any suggestions on how to proceed would be appreciated!!

SGaist

Beside having Xorg running, do you have a window manager as well ? If so which one is it ?

davethomaspilot

@SGaist LXDE

davethomaspilot

@davethomaspilot I started down the path of trying to compile my application on the RPI.

I ran out of file space when installing qtcreator. So, I deleted browsers to free up enough space to be able to clone reliably, and cloned to a 64G SD card (versus the 8 GB I was using).

Then I successfully installed qt creator.

I was struggling with configuring qtcreator to just compile a simple "hello world" QMainWindow example so blew it off for the day yesterday.

Today I started by just trying my app again. It now works fine!

Turns out after installing qtcreator, my app now runs fine!

Specifically, the menus display correctly when clicking on the menubar, and tool tips display as expected.

I made no changes to the app and I'd already set up LD_LIBRARY_PATH to use the qt libs from the 64 bit bookworm repo.

All I can figure is that I got some different version of a qt dependency when installing qtcreator and that fixed my issue.

It would be nice to understand better, but I've already spent way too much time. Since I'm now working ok, I'm moving on!

jsulm

@davethomaspilot If you just want to build on RPi you don't need QtCreator. Just install needed Qt packages and use qmake or cmake to configure and build.

davethomaspilot

@davethomaspilot Actually---

I'm running headless and using x11vnc.

Turns out when I have a display plugged into one of the RPI4 HDMI ports, the menus and tool tips work as expected. It's only when the rpi is booted with no display attached to I have the issue.

I recall a setting in /boot/config.txt that fixed some issue that could occur on a headless setup, but I it seems weird that an unconnected HDMI could cause an issue like I"m seeing. I bet there's a simple workaround though.

I'll do some more research, and if something similar isn't already known, I'll do another post that won't have all the other build stuff cluttering it.

davethomaspilot

@jsulm Thanks--

Compiling on the rpi was just to figure out what's going on. Now that I see the issue only occurs when a display is not plugged into the rpi, I think it's unrelated to the Qt6 libraries used or whether it was cross-compiled or built locally.

100% repeatable--every time I get the strange behavior if a display is not plugged into the HDMI port. Works perfectly if a display is plugged in.

I know it is not impacted by this line in /boot/config.txt:

Enable DRM VC4 V3D driver

dtoverlay=vc4-kms-v3d

That is, I have same symptom if I boot without that line in config.txt.