liri-eglfs compile error on thud

[ghost]

I am getting the compile error when building liri-eglfs on thud.

/liri/bld-liri/tmp/work/aarch64-poky-linux/liri-eglfs/0.0.0+gitAUTOINC+abe530108d-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp:375:46: error: 'QOpenGLFunctions_3_0' was not declared in this scope
auto funcs = glContext->versionFunctions<QOpenGLFunctions_3_0>();
^~~~~~~~~~~~~~~~~~~~
/liri/bld-liri/tmp/work/aarch64-poky-linux/liri-eglfs/0.0.0+gitAUTOINC+abe530108d-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp:375:46: note: suggested alternative: 'QOpenGLFunctions'
auto funcs = glContext->versionFunctions<QOpenGLFunctions_3_0>();
^~~~~~~~~~~~~~~~~~~~
QOpenGLFunctions
/liri/bld-liri/tmp/work/aarch64-poky-linux/liri-eglfs/0.0.0+gitAUTOINC+abe530108d-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp:375:68: error: no matching function for call to 'QOpenGLContext::versionFunctions< >()'
auto funcs = glContext->versionFunctions<QOpenGLFunctions_3_0>();
^

[schnitzeltony]

What does

bitbake -e qtbase | grep ′PACKAGECONFIG

say?

[ghost]

I added it in the text file.
packageconfig.txt

[schnitzeltony]

Ahh Freescale/NXP - what machine exactly?

Just what I do usually / did recently

• my reference machine is Raspi3 with open source graphics stack (VC4 / mesa)
• as far as I can remember I have built/run LIRI for imx6 (Variscite-SOM - see meta-freescale-3rd-party) with open source graphics stack (entaviv/mesa) - maybe I should try another time
• my qtbase is build with PACKAGECONFIG_GL = "gl' for two reasons: Some projects don't build with qtbase configured for gles and I could not find any performance regression yet.

So let me guess: You use vivante closed source (this either X11 or Wayland thingy...) - or do you think you can give mainline-kernel / etnaviv / qtbase for full OpenGL a try?

[schnitzeltony]

One bit off topic note: be aware that LIRI is WIP and has issues. Just to avoid disappointments...

[ghost]

I am using imx8qmmek machine.

I built Liri before for the same machine when all the yocto recipes in meta-qt5-extra pointed to old commits of Liri source. ( I think this is because Liri adapted qbs build system in between). I started building it again after i learnt that Liri moved to cmake but came across this build break.

Yes, we use vivante closed source. I am able to see those openGL functions in the sysroots of Liri-eglfs .
I will try with the mainline-kernel but not sure if it will work.

[schnitzeltony]

I built Liri before for the same machine when all the yocto recipes in meta-qt5-extra pointed to old commits of Liri source. ( I think this is because Liri adapted qbs build system in between).

Yes I did not get QBS to fly - but that is ages ago...

[schnitzeltony]

Sleeping this over made me remember: had trouble at the same code area not during build but at runtime [1].

There is some frame-recorder (enabled by default upstream - hmm) which uses OpenGL3 functions. Up to now this was was just disabled - now I removed the code completely [2].
Be aware that I rebased thud branch to master to the point just before music stuff was splitted out to meta-musicians. I did that to avoid backport dance and to get best out of thud branch.

Long talk short: pulling meta-qt5-extra/thud should fix your issue.

[1] lirios/lirios#61
[2] 2535943

[ghost]

Thank you! Pulling meta-qt5-extra/thud fixed my build break.