Home > Net >  Cannot link against cross-compiled opengl_es2 when building Qt 5.15.2 for Raspberry Pi 4 (arm64)
Cannot link against cross-compiled opengl_es2 when building Qt 5.15.2 for Raspberry Pi 4 (arm64)

Time:10-05

I'm trying to compile Qt 5.15.2 for arm64 Pi4. The configure phase fails with

ERROR: Feature 'opengles2' was enabled, but the pre-condition '(config.win32 && !features.opengl-dynamic) || (!config.watchos && !features.opengl-desktop && libs.opengl_es2)' failed.

ERROR: Feature 'eglfs' was enabled, but the pre-condition '!config.android && !config.darwin && !config.win32 && !config.wasm && features.egl' failed.

ERROR: The OpenGL functionality tests failed!

After reading the build output I see how the OpenGL test fails:

  cd /build/pi4/parts/qtbase/build/config.tests/opengl_es2 && PKG_CONFIG_SYSROOT_DIR=/ PKG_CONFIG_LIBDIR=/build/pi4/stage/usr/lib/pkgconfig:/build/pi4/stage/usr/lib/aarch64-linux-gnu/pkgconfig:/usr/lib/aarch64-linux-gnu/pkgconfig:/usr/share/pkgconfig:/usr/lib/pkgconfig /build/pi4/parts/qtbase/build/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG  = shared warn_off console single_arch" 'QMAKE_LIBDIR  = /build/pi4/stage/usr/lib/aarch64-linux-gnu' -early "CONFIG  = cross_compile" 'QMAKE_USE  = opengl_es2' 'QMAKE_LIBS_OPENGL_ES2 = -L//build/pi4/stage/usr/lib -lGLESv2' 'QMAKE_INCDIR_OPENGL_ES2 = //build/pi4/stage/usr/include' /build/pi4/parts/qtbase/build/config.tests/opengl_es2
  cd /build/pi4/parts/qtbase/build/config.tests/opengl_es2 && MAKEFLAGS= /usr/bin/make
> /usr/bin/aarch64-linux-gnu-g   -c -march=armv8-a -mtune=cortex-a72 -O2 -w -fPIC  -I. -I/build/pi4/stage/usr/include -I/build/pi4/parts/qtbase/build/mkspecs/devices/linux-rasp-pi4-v3d-g   -o main.o main.cpp
> /usr/bin/aarch64-linux-gnu-g   -Wl,-O1 -o opengl_es2 main.o   -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2   
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: warning: libglapi.so.0, needed by //build/pi4/stage/usr/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: //build/pi4/stage/usr/lib/libGLESv2.so: undefined reference to `_glapi_tls_Dispatch'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:69: opengl_es2] Error 1

But the libglapi.so.0 is exactly in -L//build/pi4/stage/usr/lib.

I executed the test step manually and it failed with the same error:

root@10cb734e2e05:~/pi4/parts/qtbase/build/config.tests/opengl_es2# /usr/bin/aarch64-linux-gnu-g   -Wl,-O1 -o opengl_es2 main.o   -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: warning: libglapi.so.0, needed by //build/pi4/stage/usr/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: //build/pi4/stage/usr/lib/libGLESv2.so: undefined reference to `_glapi_tls_Dispatch'
collect2: error: ld returned 1 exit status

But if I specify the same path /build/pi4/stage/usr/lib with -rpath, the compilation succeeds:

root@10cb734e2e05:~/pi4/parts/qtbase/build/config.tests/opengl_es2# /usr/bin/aarch64-linux-gnu-g   -Wl,-O1,-rpath=/build/pi4/stage/usr/lib -o opengl_es2 main.o   -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2

So my question is - why the linker cannot find the same library with the -L argument but can do it if I use -rpath?

CodePudding user response:

The root cause was that the linker cannot find a dependency of a dependency. LD_LIBRARY_PATH and L doesn't work in such cases. You should use -rpath-link.

You can read more details in the posts I mentioned in the end.

When compiling Qt, you can pass extra arguments for libraries you need. In my case, I had to add the following code to make it work:

QMAKE_LIBS_OPENGL_ES2 ="-Wl,-rpath,${SNAPCRAFT_STAGE}/usr/lib/" \
QMAKE_LIBS_EGL ="-Wl,-rpath,${SNAPCRAFT_STAGE}/usr/lib/" \

My solution is based on this post: Why does ld need -rpath-link when linking an executable against a so that needs another so?

and this article: Why does ld need -rpath-link when linking an executable against a so that needs another so?

  • Related