AnsweredAssumed Answered

Qt5 app using GLESv2 fails to build against Yocto Application SDK

Question asked by Bruce Bye on Jun 25, 2015
Latest reply on Jun 29, 2015 by Bruce Bye

Hi,

 

I'm trying to use the Yocto BSP (dizzy) to create an application SDK that includes Qt5 - I'm using meta-qt5's meta-toolchain-qt5 recipe to do this.  I got to the point where a simple Qt5 app successfully compiles against the SDK produced, but I have another app which uses GLESv2 and for this qmake fails.

 

The issue appears to be that the Qt5GuiConfigExtras.cmake file generated has incorrect paths.  The initial error is that it's looking for the header file "GLES2/gl2.h" in "/usr/include/libdrm", rather than {path-to-target-sysroot}/usr/include.  There are also two calls to _qt5gui_find_extra_libs towards the end of the file which pass in the path of the original Yocto build environment rather than the extracted SDK.

 

I've worked around these post-install of the SDK by lifting code from Qt5LocationConfig.cmake to determine _qt5Gui_install_prefix and use that in the three places (and appending /include in addition to /include/libdrm where it is seeking gl2.h).  This allows qmake to succeed and the app builds.

 

However...I'd like to be able to generate an application SDK that doesn't need post-install patching in this way, and it's not obvious how the various variables relate to one another (and when they are acted on, in some cases) in Qt5GuiConfigExtras.cmake.in.  In particular, is there an error in the variables being set when qmake acts on gui.pro, a bug in the .cmake.in script, or both?

 

In case it's relevant, my target machine is imx6qsabreauto.

 

Thanks,

Bruce

Outcomes