qt cross compilation for raspberry pi: Cannot find GLESv2

Question

I am trying to compile qt 5.9 for my raspberry pi 3 compute module and I have been following mainly the online guide here (https://wiki.qt.io/RaspberryPi2EGLFS). So

Answer 1

This is the qmake.conf I used (it worked for me):

include(../common/linux_device_pre.conf)

QMAKE_LFLAGS           += -Wl,-rpath-link,$$[QT_SYSROOT]/opt/vc/lib
QMAKE_LFLAGS           += -Wl,-rpath-link,$$[QT_SYSROOT]/home/pi/qtdeps/lib

QMAKE_LIBDIR_OPENGL_ES2 = $$[QT_SYSROOT]/opt/vc/lib
QMAKE_LIBDIR_EGL        = $$QMAKE_LIBDIR_OPENGL_ES2
QMAKE_LIBDIR_OPENVG     = $$QMAKE_LIBDIR_OPENGL_ES2

QMAKE_INCDIR_EGL        = $$[QT_SYSROOT]/opt/vc/include \
                          $$[QT_SYSROOT]/opt/vc/include/interface/vcos/pthreads \
                          $$[QT_SYSROOT]/opt/vc/include/interface/vmcs_host/linux

QMAKE_INCDIR_OPENGL_ES2 = $${QMAKE_INCDIR_EGL}
QMAKE_INCDIR_OPENVG     = $${QMAKE_INCDIR_EGL}

QMAKE_LIBS_EGL          = -lEGL -lGLESv2
QMAKE_LIBS_OPENVG       = -lEGL -lOpenVG -lGLESv2

QMAKE_CFLAGS            = -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8
QMAKE_CXXFLAGS          = $$QMAKE_CFLAGS

DISTRO_OPTS            += hard-float
DISTRO_OPTS            += deb-multi-arch

# Preferred eglfs backend
EGLFS_DEVICE_INTEGRATION= eglfs_brcm

include(../common/linux_arm_device_post.conf)

load(qt_config)

Answer 2

In Raspbian Stretch "rpi-update" must be invoked, otherwise "libGLESv2.so" is missing in /opt/vc/lib. This fixes the linker error "cannot find -lGLESv2"

https://www.raspberrypi.org/forums/viewtopic.php?t=191638

update: the previously mentioned solution may have some unwanted side effects. I therefore recommend doing this instead::

ln -s libbrcmEGL.so /opt/vc/lib/libEGL.so
ln -s libbrcmGLESv2.so /opt/vc/lib/libGLESv2.so
ln -s libbrcmOpenVG.so /opt/vc/lib/libOpenVG.so
ln -s libbrcmWFC.so /opt/vc/lib/libWFC.so

Answer 3

My starting point was 2017-11-29-raspbian-stretch and built my toolchain in OSX using crosstool-ng.

While sudo rpi-update helped and brought in 'libGLESv2.so', it did not solve the problem for me. The issue turned out to be in the QT configuration. QT uses gcc -dumpmachine to establish the tuple. For me it was 'arm-raspbian-linux-gnueabihf'. QT ends up searching for libraries and packages in locations like /usr/lib/arm-raspbian-linux-gnueabihf which do not exist. (It ends up failing to find libraries like 'libpthread.so' while compiling using GLESv2.) Instead, if you look at the OS, the correct location is /usr/lib/arm-linux-gnueabihf. The solution is to modify 'configure.pri' in qtbase.

--- a/configure.pri
+++ b/configure.pri
@@ -241,7 +241,7 @@ defineReplace(qtConfFunc_licenseCheck) {

 # this is meant for linux device specs only
 defineTest(qtConfTest_machineTuple) {
-    qtRunLoggedCommand("$$QMAKE_CXX -dumpmachine", $${1}.tuple)|return(false)
+    qtRunLoggedCommand("$$QMAKE_CXX -dumpmachine | sed 's/-raspbian//'", $${1}.tuple)|return(false)
     $${1}.cache += tuple
     export($${1}.cache)
     return(true)

This changes the tuple from crosstool-ng to the triplet.

Update. If you are using crosstool-ng, an alternative to this "fix" is to use CT_TARGET=arm-linux-gnueabihf (not CT_TARGET_ALIAS).