I am trying to add the nativesdk-qt4-tools to my yocto SDK. I expect the libraries to be usable for host executables (used during the build process).
I have added the following to my core-image-x11.bbappend file:
TOOLCHAIN_HOST_TASK_append = "\
nativesdk-packagegroup-qt-toolchain-host \
"
TOOLCHAIN_TARGET_TASK_append = "\
qt4-x11-free \
"
When I look in the target SDK directory I find the qt libraries such as:
<path>/sysroots/arm1176jzfshf-vfp-poky-linux-gnueabi/usr/lib/libQtCore...
I expect to find the same files in the host SDK; however, they are absent:
ls <path>/sysroots/x86_64-pokysdk-linux/usr/lib/libQt*
ls: cannot access '<path>/sysroots/x86_64-pokysdk-linux/usr/libQt*': No such file or directory
I have tried several different Qt4 recipes in TOOLCHAIN_HOST_TASK_append, I have also tried to add the same recipes to INSTALL_IMAGE += "..." but none have had the effect I am looking for.
Online advice suggests that I could run
bitbake -c populate_sdk meta-toolchain-qt
however this also does not install the necessary libraries.
There are several solutions for Qt5 but none of them apply to Qt4. Unfortunately this is not a personal project, so upgrading to Qt5 is out of the question.
It turns out the problem was trying to use the wrong tool for the job. From the online documentation (which a colleague pointed out to me)
What does "native" mean?
The "native" suffix identifies recipes (and variants of recipes) that produce files intended for the build host, as opposed to the target machine. This is usually for tools that are needed during the build process (such as automake).
What does "nativesdk" mean?
The "nativesdk" prefix identifies recipes (and variants of recipes) that produce files intended for the host portion of the standard SDK, or for things which are constructed like an SDK such as buildtools-tarball. These are built for SDKMACHINE which may or may not be the same architecture as the build host.
The correct solution was not to play with the nativesdk build setup, but rather to build for an emulator that would be closer matched to the host system (such as qemux86 or qemux86_64). When the SDK was created for the emulators we could use that SDK to build new libraries and executables to run on host using the same software versions as used for the target systems.