How to configure QtCreator with Yocto sysroots
-
I successfully built a Yocto project that contains the
meta-qt5
layer.
At the end, I found:tmp-glibc/sysroots-components/x86_64/qtbase-native/usr/bin/qmake tmp-glibc/sysroots-components/x86_64/qtbase-native/usr/lib/libQt5Core.so.5.11 tmp-glibc/sysroots-components/cortexa7t2hf-neon-vfpv4/qtbase/usr/lib/libQt5Core.so.5.11
Of course along the other libraries, but it's just to show you the path.
I went to the QtVersions tab of QtCreator, added a new one and selected the aboveqmake
.
QtCreator says:Qt version is not property installed, please run make install
Why? I mean, what does this error imply? What is it looking for that it doesn't find?
After fixing this (hopefully!) I need to create the Kit. As sysroot I need to select
tmp-glibc/sysroots-components/cortexa7t2hf-neon-vfpv4/qtbase
? -
Hi,
Did you try to run that qmake version directly in your command prompt ?
-
I successfully built a Yocto project that contains the
meta-qt5
layer.
At the end, I found:tmp-glibc/sysroots-components/x86_64/qtbase-native/usr/bin/qmake tmp-glibc/sysroots-components/x86_64/qtbase-native/usr/lib/libQt5Core.so.5.11 tmp-glibc/sysroots-components/cortexa7t2hf-neon-vfpv4/qtbase/usr/lib/libQt5Core.so.5.11
Of course along the other libraries, but it's just to show you the path.
I went to the QtVersions tab of QtCreator, added a new one and selected the aboveqmake
.
QtCreator says:Qt version is not property installed, please run make install
Why? I mean, what does this error imply? What is it looking for that it doesn't find?
After fixing this (hopefully!) I need to create the Kit. As sysroot I need to select
tmp-glibc/sysroots-components/cortexa7t2hf-neon-vfpv4/qtbase
?@Mark81 I don't know if it's possible to do what you currently try.
But it is possible to build a SDK:
bitbake meta-toolchain-qt5
. That gives you an installer that can be used on different workstations to cross-build Qt5 projects.At least that's how we do it.
Regards
-
@Mark81 I don't know if it's possible to do what you currently try.
But it is possible to build a SDK:
bitbake meta-toolchain-qt5
. That gives you an installer that can be used on different workstations to cross-build Qt5 projects.At least that's how we do it.
Regards
@aha_1980 said in How to configure QtCreator with Yocto sysroots:
But it is possible to build a SDK:
bitbake meta-toolchain-qt5
. That gives you an installer that can be used on different workstations to cross-build Qt5 projects.It's building right now. At the end (it's going to take many hours...) I will give a feedback. Thanks!
-
Unfortunately, it tries to build qtwebkit and fails, but I don't want it.
So I edit the filemeta-qt5/recipes-qt/packagegroups/packagegroup-qt5-toolchain-target.bb
removing the modules I'm not interested into. Then,bitbake -c clean meta-toolchain-qt5 bitbake meta-toolchain-qt5
but now it returns a lot of errors that weren't there on the first "baking":
ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy_setscene: The recipe nativesdk-sdcard-raw-tools is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts/create_sdcard_from_flashlayout.sh (matched in manifest-stm32mp1-sdcard-raw-tools-native.deploy) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy_setscene: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. WARNING: Logfile for failed setscene task is /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/x86_64-nativesdk-openstlinux_eglfs_sdk-linux/nativesdk-sdcard-raw-tools/1.0-r0/temp/log.do_deploy_setscene.3890 WARNING: Setscene task (virtual:nativesdk:/local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/layers/meta-st/meta-st-stm32mp/recipes-devtools/sdcard-raw-tools/sdcard-raw-tools.bb:do_deploy_setscene) failed with exit code '1' - real task will be run instead NOTE: Executing RunQueue Tasks ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: The recipe nativesdk-sdcard-raw-tools is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts/create_sdcard_from_flashlayout.sh (matched in manifest-stm32mp1-sdcard-raw-tools-native.deploy) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: Function failed: sstate_task_postfunc ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/x86_64-nativesdk-openstlinux_eglfs_sdk-linux/nativesdk-sdcard-raw-tools/1.0-r0/temp/log.do_deploy.3925 ERROR: Task (virtual:nativesdk:/local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/layers/meta-st/meta-st-stm32mp/recipes-devtools/sdcard-raw-tools/sdcard-raw-tools.bb:do_deploy) failed with exit code '1'
And worst, it still tries to build qtwebkit! Isn't the clean command enough to rebuild the package?
-
Unfortunately, it tries to build qtwebkit and fails, but I don't want it.
So I edit the filemeta-qt5/recipes-qt/packagegroups/packagegroup-qt5-toolchain-target.bb
removing the modules I'm not interested into. Then,bitbake -c clean meta-toolchain-qt5 bitbake meta-toolchain-qt5
but now it returns a lot of errors that weren't there on the first "baking":
ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy_setscene: The recipe nativesdk-sdcard-raw-tools is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts/create_sdcard_from_flashlayout.sh (matched in manifest-stm32mp1-sdcard-raw-tools-native.deploy) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy_setscene: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. WARNING: Logfile for failed setscene task is /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/x86_64-nativesdk-openstlinux_eglfs_sdk-linux/nativesdk-sdcard-raw-tools/1.0-r0/temp/log.do_deploy_setscene.3890 WARNING: Setscene task (virtual:nativesdk:/local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/layers/meta-st/meta-st-stm32mp/recipes-devtools/sdcard-raw-tools/sdcard-raw-tools.bb:do_deploy_setscene) failed with exit code '1' - real task will be run instead NOTE: Executing RunQueue Tasks ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: The recipe nativesdk-sdcard-raw-tools is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/deploy/images/stm32mp1/scripts/create_sdcard_from_flashlayout.sh (matched in manifest-stm32mp1-sdcard-raw-tools-native.deploy) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. ERROR: nativesdk-sdcard-raw-tools-1.0-r0 do_deploy: Function failed: sstate_task_postfunc ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/x86_64-nativesdk-openstlinux_eglfs_sdk-linux/nativesdk-sdcard-raw-tools/1.0-r0/temp/log.do_deploy.3925 ERROR: Task (virtual:nativesdk:/local/STM32MP15-Ecosystem-v1.0.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-02-20/layers/meta-st/meta-st-stm32mp/recipes-devtools/sdcard-raw-tools/sdcard-raw-tools.bb:do_deploy) failed with exit code '1'
And worst, it still tries to build qtwebkit! Isn't the clean command enough to rebuild the package?
-
Yocto is a monster. Honestly, I don't know the correct way to do so, but to get a really clean try we remove the following directories:
sstate-cache tmp-glibc deploy/ipk cache
Than start to rebuild.
-
@aha_1980 thanks. I'll do it.
Just to be sure: it's ok my edit to avoid the building of qtwebkit?@Mark81 said in How to configure QtCreator with Yocto sysroots:
Just to be sure: it's ok my edit to avoid the building of qtwebkit?
I'd say yes. But I'm still learning Yocto on my way, and the way is hard.
Regards