Menus from QMainWindow MenuBar not showing on Qt 6.4.0

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.

davethomaspilot

@davethomaspilot QtCreator installed from the repo has the same issue---

I was going to build a trivial example but I found QtCreator installed from the repo has the same issue.

If I boot without a display connected, menus don't display when I click on File, Edit, View ... on the qtcreator menubar.

Everything works fine if a display is connected.

Can someone see if they see the same?

RPI4, bookworm 64 bit.

(Both cases using a vnc session).

So, this really seems like a bug--not sure if it's a Qt bug or something in bookworm. Advice on where to post?

davethomaspilot

@davethomaspilot lximage-qt works fine with nothing plugged into the HDMI port.

But, it's build with qt5 libraries.

ldd /usr/bin/lximage-qt
	linux-vdso.so.1 (0x0000007fa4c7e000)
	libfm-qt.so.12 => /lib/aarch64-linux-gnu/libfm-qt.so.12 (0x0000007fa4a20000)
	libQt5Network.so.5 => /lib/aarch64-linux-gnu/libQt5Network.so.5 (0x0000007fa4840000)
	libQt5DBus.so.5 => /lib/aarch64-linux-gnu/libQt5DBus.so.5 (0x0000007fa4780000)
	libQt5PrintSupport.so.5 => /lib/aarch64-linux-gnu/libQt5PrintSupport.so.5 (0x0000007fa46e0000)
	libQt5X11Extras.so.5 => /lib/aarch64-linux-gnu/libQt5X11Extras.so.5 (0x0000007fa46b0000)
	libQt5Svg.so.5 => /lib/aarch64-linux-gnu/libQt5Svg.so.5 (0x0000007fa4630000)

davethomaspilot

@davethomaspilot I created a new bookworm, 64 bit image for RPI4 using the raspberry pi imager.

Yes, same behavior using fresh bookworm 64 bit from the Raspberry Pi imager.

Used raspi-config to choose X11, installed x11vnc, and qtcreator

qtcreator works fine if something is plugged into the HDMI connector (even when using vnc connection). When booted with nothing plugged into the HDMI connector, the menus (and tool tips) fail to display from the qtcreator menubar.

Same symptoms I first saw in my application and was blaming on something I had done wrong in the qt build process.

Now, just using the repo QT6 libs, I see same issue in qtcreator

I think there must be an issue in a Qt 6.4.2 .so.

I'll create a new post since this one has gotten so long nobody will read it.

Hopefully there's a work-around hdmi_force_hotplug=1 does not help.

Maybe later versions don't have this issue? Is there a way to try that without building Qt from source?

davethomaspilot

@davethomaspilot I found a post that said the latest version of bookworm doesn't use config.txt, at least not for hdmi_force_hotplug . It suggested using cmdline.txt instead and using:

[code]video=HDMI-A-1:1920x1080M@60D[/code]

at the beginning of the cmdline.txt line.

This fixes the issue!

Apparently, without this change (regardless of what's in config.txt), display resolution is something that's incompatible with qt6 Qmenubar (and tool tips). The display looks very small--I think that means higher resolution that what I normally use (1920x1080).

Anyway, now that I have a workaround, I'm "outta here". But, this will probably will catch others that have depended on config.txt for headless operation.