Menus from QMainWindow MenuBar not showing on Qt 6.4.0
-
@davethomaspilot Are you using X11 or Wayland on the device? If Wayland try to switch to X11 to see whether it makes a difference. You can also test with some preinstalled Qt application like VLC.
@jsulm Thanks for your help!
I configured the build for FEATURE_xcb=ON. Here are the other configuration options I used:
-release
-opengl
es2
-nomake
examples
-nomake
tests
-qt-host-path
/home/davethomaspilot/qt-host
-extprefix
/home/davethomaspilot/qt-raspi
-prefix
/usr/local/qt6
-device
linux-rasp-pi4-aarch64
-device-option
CROSS_COMPILE=aarch64-linux-gnu--DCMAKE_TOOLCHAIN_FILE=/home/davethomaspilot/toolchain.cmake
-DQT_FEATURE_xcb=ON
-DFEATURE_xcb_xlib=ON
-DQT_FEATURE_xlib=ON -
@jsulm Thanks for your help!
I configured the build for FEATURE_xcb=ON. Here are the other configuration options I used:
-release
-opengl
es2
-nomake
examples
-nomake
tests
-qt-host-path
/home/davethomaspilot/qt-host
-extprefix
/home/davethomaspilot/qt-raspi
-prefix
/usr/local/qt6
-device
linux-rasp-pi4-aarch64
-device-option
CROSS_COMPILE=aarch64-linux-gnu--DCMAKE_TOOLCHAIN_FILE=/home/davethomaspilot/toolchain.cmake
-DQT_FEATURE_xcb=ON
-DFEATURE_xcb_xlib=ON
-DQT_FEATURE_xlib=ON@davethomaspilot And, I have X11 configured using raspi-config on the rpi4.
-
@davethomaspilot And, I have X11 configured using raspi-config on the rpi4.
@davethomaspilot Yes, looks like you're using X11.
Could be that there is an issues with Qt6 and that OS version. -
@davethomaspilot Yes, looks like you're using X11.
Could be that there is an issues with Qt6 and that OS version.@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!
-
@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!
@davethomaspilot hi,
Unless you installed your cross-compiled Qt in system folders (which you should not), installing the distribution packages should not interfere with them.
-
@davethomaspilot hi,
Unless you installed your cross-compiled Qt in system folders (which you should not), installing the distribution packages should not interfere with them.
@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/vcwhich 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 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/vcwhich 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?
@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 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.
@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).
-
@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).
@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 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.
@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 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.
@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 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.
@jsulm So as not to clobber the Qt libs I built. Compile time is measured in days.
-
@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 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 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 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 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 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 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!!
-
@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!!
Beside having Xorg running, do you have a window manager as well ? If so which one is it ?
-
@SGaist LXDE
-
@SGaist LXDE
@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!
-
@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!
@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.